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Abstract. 

The  Virtual  Time  CSMA  protocol,  presented  by  M.  Molle,  is  studied  using  a 
detailed  simulation  model  Simulation  allows  us  to  faithfully  represent  asyn¬ 
chronous  (unslotted)  operation  of  the  protocol,  to  correctly  model  the  blocking 
effects  due  to  finite  message  buffers  at  the  stations,  and  also  to  model  the  exact 
details  of  a  variety  of  sophisticated  retransmission  strategies  for  handling  colli¬ 
sions.  Several  experiments  are  conducted.  The  results  support  analytical  stu¬ 
dies  showing  that  virtual  time  CSMA  can  attain  higher  throughput  and  better 
delay  and  blocking  performance  than  1-persistent  CSMA,  and  that  further  per¬ 
formance  gains  occur  when  the  obvious  retransmission  strategies  are  replaced 
by  a  novel  method  called  an  asynchronous  stack  algorithm.  Multi-Prioritized 
environments  are  also  studied,  using  generalizations  of  single  priority  algo¬ 
rithms. 
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Chapter  1. 


1.  Introduction. 

The  rapid  evolution  of  electronics  in  the  last  decade  allowed  the  computer 
industry  to  develop  low  cost  and  highly  reliable  computer  systems  for  almost 
every  application,  giving  rise  to  environments  where  within  a  building,  or  a 
small  group  of  buildings,  many  different  computers,  minicomputers  and  intelli¬ 
gent  microprocessor  driven  devices  are  used.  The  need  to  interconnect  them 
in  a  uniform  and  reliable  manner  has  led  to  the  design  of  local  area  computer 
networks  of  different  types.  Packet  radio  technology  also  has  advanced  to  the 
point  where  it  is  feasible  to  interconnect  several  computers  through  a  radio 
channel,  while  optical  fibres  are  now  available  offering  high  capacity  in  low 
cost.  As  a  result  to  all  these,  communication  networks  using  a  single  (or  in 
some  cases  double)  channel  evolved  and  have  been  implemented  on  several 
media,  notably  radio  channels  (satellite  and  ground  radio  channels),  wires 
(twisted  pairs  and  coaxial  cables),  and  optical  fibres.  These  type  of  networks 
using  a  common  channel  are  known  as  multiple  access  networks  and  have  been 
implemented  on  several  topologys  (fully  connected,  star,  linear  or  bus,  ring 
etc.). 

Several  control  techniques  have  been  developed  to  support  multiple  access 
networks.  When  the  network  must  support  many  bursty  stations  random  access 
techniques  are  the  most  efficient  of  all.  These  can  support  a  variety  of  network 
loads  and  stations,  without  significant  problems.  The  control  for  channel 
access  in  random  access  techniques  varies  from  non-existent  to  highly  con¬ 
trolled.  In  the  pure  ALOHA  [l]  for  example,  there  is  almost  no  control.  When¬ 
ever  a  station  has  a  packet  to  transmit,  it  simply  transmits  it.  If  more  than  one 
station  transmits  a  message  at  the  same  time  a  conflict,  or,  as  it  is  commonly 
named,  a  collision,  occurs  and  all  of  the  packet  transmissions  are  lost.  After  a 
message  has  collided  (which  is  detected  by  the  absence  of  acknowledgement 
from  the  destination),  it  must  be  retransmitted  after  a  random  delay.  Colli¬ 
sions  in  the  pure  ALOHA  system,  lead  to  a  serious  degradation  of  the  channel 

when  it  is  heavily  loaded,  placing  a  limit  of  ■—  ^  18%  on  the  channel  capacity. 

An  improvement  of  this  performance  can  be  achieved  if  the  time  is  considered 
slotted  and  the  stations  can  transmit  only  at  the  beginning  of  a  slot.  This  way 

the  channel  capacity  can  increase  up  to  —  «  36%  [26]. 

6 

A  more  advanced  idea  which  takes  advantage  of  the  feedback  that  a  colli¬ 
sion  occurred  sometime  in  the  past,  was  suggested  by  Capetanakis  [4].  The 
idea  here  is  that  whenever  a  collision  occurs  all  stations  involved  in  it  are 
divided  into  two  groups.  Stations  in  the  first  group  will  transmit  as  soon  as  the 
channel  becomes  idle,  while  the  other  group  will  wait  until  those  in  the  first 
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group  have  transmitted  their  packets  successfully.  That  type  of  collision  reso¬ 
lution  algorithm  is  known  as  a  tree  algorithm.  Tree  algorithms  suffer  two  major 
problems  from  a  practical  point  of  view.  The  first  is  failure  due  to  incorrect  or 
inconsistent  feedback  (eg.  deadlock).  The  second  is  that  the  current  "state"  of 
the  protocol  encodes  the  channel  activity  for  a  long  time  in  the  past,  so  that 
stations  may  have  difficulty  entering  or  leaving  the  network.  Thus  for  practical 
systems  may  not  be  the  best  choice,  especially  for  local  area  networks  where 
the  performance  advantage  of  tree  algorithm  (if  any)  is  small. 

In  the  case  where  the  transmission  medium  is  a  coaxial  cable,  twisted  pair, 
or  a  radio  channel,  the  feature  of  carrier  sensing  is  available,  i.e.,  the  station 
can  sense  whether  or  not  there  is  a  message  in  the  channel  and,  if  so,  delay 
transmitting  its  packet.  Control  techniques  which  sense  the  channel  before 
transmitting,  are  called  Carrier  Sense  -  Multiple  Access  (CSMA)  techniques.  The 
most  important  techniques  of  that  type  are  the  non-persistent  and  p-persistent 
CSMA  protocols  [16].  The  idea  in  these  protocols  is  to  sense  the  state  of  the 
channel  before  transmitting  a  packet.  If  it  is  idle,  the  packet  is  transmitted 
immediately.  Otherwise  the  transmission  must  be  delayed.  In  the  non- 
persistent  protocol,  the  transmission  attempt  is  aborted  (as  if  a  collision  had 
occurred)  so  that  the  packet  must  be  rescheduled  for  transmission  after  a  ran¬ 
dom  delay.  In  the  p-persistent  protocol,  the  station  will  continue  sensing  the 
channel  until  it  becomes  idle,  and  thereafter  will  either  transmit  it  with  proba¬ 
bility  p  ,  or  delay  its  transmission  for  a  short  time  and  repeat  the  algorithm 
with  probability  1-p  .  This  way  the  channel  capacity  can  increase  depending  on 
the  normalized  idle  and  collision  detect  times. 

Certain  media,  such  as  coaxial  cable,  also  allow  collision  detection,  i.e.,  the 
station  can.  sense  whether  or  not  its  message  is  colliding  with  other  message(s) 
and  stop  transmitting  immediately.  Obviously  this  feature  can  increase  the 
channel  utilization,  when  used  properly. 

Another  class  of  CSMA  protocols  are  the  virtual  time  CSMA  (  VT-CSMA  )  pro¬ 
tocols,  presented  by  M.Molle  in  his  Ph.D.  thesis  in  1981  [23].  The  new  idea  of 
the  VT-CSMA  protocols  is  that  the  stations  use  a  virtual  clock  to  schedule  their 
message  transmissions.  The  virtual  clock  runs  faster  than  real  time,  but  only 
when  the  channel  is  idle,  providing  for  each  message  a  "virtual"  arrival  time 
during  channel  idle  period.  It  was  proven  by  Molle  that  the  minislotted  VT-CSMA 
protocols  are  optimal  over  all  possible  CSMA  variants,  under  some  commonly 
applied  assumptions. 

In  this  work  we  will  explore  the  unslotted  versions  of  the  VT-CSMA  proto¬ 
cols,  and  obtain  results  concerning  their  optimality  and  functional 
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characteristics.  In  chapter  2  we  summarize  the  results  from  the  original 
analysis  in  [23].  In  chapter  3  some  practical  problems  concerning  the  protocol 
are  presented.  In  Chapter  4  the  specifications  of  the  simulation  are  given, 
while  chapter  5  describes  the  simulation  program  itself.  Chapter  6  presents 
the  simulation  results  concermng  single  priority  networks,  while  Chapter  6 
discusses  some  ideas  for  expanding  the  existing  collision  resolution  algorithms 
so  that  more  priority  classes  to  be  considered,  giving  also  some  simulation 
results.  Finally  chapter  8  presents  the  final  conclusions  of  this  work. 
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2.  The  VT-CSMA  Protocol. 

A  multiple  access  protocol  is,  in  general,  an  algorithm  for  partitioning  the 
set  of  messages  in  a  network  until  each  message  is  sufficiently  isolated  to  be 
transmitted  without  interference.  Most  CSMA  protocols  depend  heavily  on  ran¬ 
domization  to  achieve  this  partitioning.  This  way  message  delays  are 
inherently  highly  variable  and  can  be  very  long,  making  the  protocols  unsuit¬ 
able  for  applications  such  as  packetized  voice  transmissions,  which  are  sensi¬ 
tive  to  both  the  mean  and  the  variance  of  delay. 

The  goal  of  the  VT-CSMA  protocol  is  to  reduce  the  mean  and  variance  of 
delay  over  other  CSMA  protocols.  This  goal  is  achieved  by  simply  observing  that 
the  differences  in  generation  time  between  messages  are  usually  large  enough 
for  a  protocol  to  distinguish  between  the  messages.  VT-CSMA  operates  in  a  way 
that  preserves  those  differences  and  uses  random  rescheduling  only  if  two  mes¬ 
sages  have  arrived  "too  closely"  in  time. 

2.1.  General  description  of  the  VT-CSMA  algorithm. 

In  a  network  working  under  the  VT-CSMA  protocol,  each  station  will  be 
equipped  with  two  clocks,  C  and  C' ,  giving  the  real  time  r  and  virtual  time  r' 
respectively. 

We  assume  that  at  time  0  both  clocks'  readings  were  0.  The  real  time  clock 
runs  at  real  time,  while  the  virtual  clock  behaves  as  follows.  When  the  channel 
is  sensed  busy  the  virtual  clock  is  stopped;  whenever  the  channel  is  sensed  idle, 
the  virtual  clock  is  enabled  to  run,  at  rate  77  (77  >  1)  times  real  time  if  t'  <  r, 
and  at  real  time  otherwise. 

When  a  new  message,  m,  is  generated,  its  real  generation  time  rm  is 
recorded.  We  shall  permit  this  message  to  be  transmitted  as  soon  as  the  virtual 
clock's  reading  becomes  rm.  Each  message  will  be  delivered  successfully, 
unless  some  other  transmission  begins  during  the  "vulnerable  period"  before 
its  signal  has  propagated  to  all  parts  of  the  network. 

We  can  easily  extent  the  protocol  for  environments  where  more  than  one 
priority  class  compete  for  channel  access.  In  this  case  each  priority  class  will 
maintain  a  different  virtual  clock,  with,  in  general,  a  different  clock  rate,  say  77* 
for  class  i.  Whenever  the  channel  becomes  idle,  (either  after  a  successfully 
transmitted  message  or  after  a  collision),  the  highest  priority  virtual  clock  will 
start  running  at  rate  77 x.  When  as  it  catches  up  with  real  time,  it  must  slow 
down  to  real  time  and  the  second  priority  class’s  clock  will  start  running  at  rate 
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r)2-  When  it  catches  up  with  real  time,  it  will  slow  down  to  real  time  and  the 
next  priority  class’s  clock  will  start  running,  and  so  on  until  all  classes’  virtual 
clocks  catch  up  with  real  time. 

As  it  can  be  seen  the  protocol  preserves,  in  general,  the  FCFS  discipline 
among  classes,  while  in  a  prioritized  environment  it  gives  immediate  channel 
access  to  the  higher  classes  allowing  the  lower  classes  to  access  the  channel 
only  when  there  is  no  backlog  of  transmission  requests  from  higher  priority 
classes.  In  addition,  extending  the  protocol  to  handle  multiple  priority  classes 
does  not  create  any  additional  channel  overhead. 


2.2.  Performance  of  the  protocol. 


For  the  performance  of  the  protocol  we  assume  an  infinite  number  of  sta¬ 
tions  generating  new  messages  of  unit  length,  according  to  a  Poisson  process, 
offering  a  total  load  of  intensity  G  to  the  network.  Also  we  assume  that  the  pro¬ 
pagation  across  the  network  require  a  fraction  a  <  1  of  a  message  transmission 
time.  Whenever  a  collision,  occurs  the  sending  stations  stop  transmitting  after 
a  fraction  b  <  1  of  each  message  has  been  transmitted.  This  way  collisions 
occupy  the  channel  for  a  total  time  a  +b  . 

For  the  above  model,  as  we  approach  capacity,  the  system  will  almost 
always  have  a  backlog,  and  therefore  we  may  assume  that  the  the  arrival  rate  is 
G'  =  rjG,  where  rj  is  the  virtual  clock  rate.  Assuming  that  each  idle  period  has 

an  average  length  of  —  and  calculating  for  the  worst  case,  it  was  proven  by 

Molle  [23]  that  the  throughput  equation  for  the  unslotted  protocol  is 


P  = 


G'e 


-aG' 


G'^Za  +6  +(l— 6  )e  ~aG 


-he 


—nG" 


and  for  the  minislotted  protocol  is 


(2.2.1) 


P  ~ 


aG'e 


-aC 


1  — e 


“a  G* 


-ha+a G'e  aG'(l—b) 


(2.2.2) 


These  equations  are  identical  to  the  throughput  equations  for  the  non- 
persistent  CSMA.  Thus  the  VT-CSMA  must  have  the  same  theoretical  capacity  as 
non-persistent  CSMA.  That  is  because  the  only  difference  in  VT-CSMA  and  non- 
persistent  CSMA  is  the  method  by  which  the  arrivals  are  disabled  when  the 
channel  is  busy.  The  major  difference  is  that  VT-CSMA  has  improved  stability 
and  delay  characteristics  over  the  non-persistent  CSMA,  because  messages  are 
queued  for  access  to  the  channel. 
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As  an  example  consider  the  case  where  a  =  .01  and  6  =  1.  Optimizing 
(2.2. 1-2. 2. 2)  over  G',  we  find  a  capacity  of  R*  .815  in  the  unslotted  case  when 
G'  »  9.45,  and  capacity  of  R*  .865  in  the  minislotted  case  when  G'  R*  13.45.  Thus 
in  the  minislotted  case  the  probability  that  a  message  is  successfully  transmit¬ 
ted  at  any  attempt,  when  we  operate  at  capacity,  is  e~aG‘  »  .874,  giving  «  1.144 
as  the  expected  number  of  attempts  per  message.  For  slotted  non-persistent 
CSMA,  the  probability  that  a  message  is  transmitted  at  a  random  attempt  is 

a 

1—e  ~aG' 

which  declines  to  R*  .0736  at  capacity,  giving  R*  15.5  as  the  expected  number  of 
attempts  per  message. 

The  optimality  of  the  VT-CSMA  minislotted  protocols,  was  proven  by  Molle 
under  the  following  assumptions  [23]. 

Assume  ; 

Al.  The  protocol  supports  an  infinite  population  of  homogeneous  stations. 

A2.  Each  message  is  immediately  and  irretrievably  lost  after  its  first  transmis¬ 
sion  attempt  on  the  channel,  whether  or  not  it  was  successful. 

A3.  No  explicit  protocol  messages  may  be  exchanged  over  the  channel:  stations 
may  only  announce  that  they  have  a  message  to  send  by  actually  transmit¬ 
ting  it. 

A4.  All  transmissions  are  synchronized  to  start  at  the  beginning  of  a  minislot, 

i.e.,  each  transmission  starts  at  time  Ka,  K=  0,1 . where  a  is  the  nor¬ 

malized  propagation  time  between  stations  in  the  network. 

Then  for  any  given  values  of  a>0  and  1>6>0: 

1.  No  protocol  can  achieve  a  higher  capacity  than  the  best  virtual  time  CSMA 
protocol,  which  we  obtain  by  optimizing  77  as  a  function  of  a  and  6  . 

2.  For  any  feasible  value  of  throughput,  there  exists  a  virtual  time  CSMA  pro¬ 
tocol  that  achieves  the  lowest  probability  of  loss  of  any  protocol. 

3.  Given  any  constraint  on  the  maximum  probability  of  loss  for  messages  in 
each  slot  not  exceeding  the  loss  probability  at  maximum  capacity,  there 
exists  a  virtual  time  CSMA  protocol  that  achieve  the  lowest  average  delay 
for  unblocked  messages  at  all  feasible  values  of  throughput. 
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4.  The  optimal  virtual  time  CSMA  protocol  described  immediately  above  also 
achieves  the  lowest  variance  of  delay  for  unblocked  messages  over  all  pro¬ 
tocols  that  achieve  the  lowest  average  delay. 

The  analytic  results,  concerning  the  delay  characteristics  of  the  protocol, 
are  shown  in  Figure  2.1  in  comparison  with  existing  CSMA  protocols. 


NORMALIZED  DELAY 
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Figure  2.1.  Comparison  of  Throughput-Delay  Tradeoffs 
with  Existing  CSMA  Protocols. 
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3.  A  practical  approach  to  the  protocol. 

Trying  to  obtain  an  indepth  understanding  of  the  protocol  and  its  behavior 
in  an  unslotted  environment,  we  found  some  interesting  details,  which  we  will 
present  in  this  chapter.  Analyzing  these  details  is  important  because  they 
represent  practical  problems  that  have  to  be  faced  in  implementation,  and  can¬ 
not  easily  be  included  in  the  theoretical  analysis.  Although  the  following  dis¬ 
cussion  refers  to  the  VT-CSMA  protocol,  the  ideas  presented  and  results 
obtained  can  be  applied  to  any  CSMA  protocol. 

3.1.  Synchronization  on  a  two  station  Network. 

Since  the  VT-CSMA  protocol  operates  according  to  the  readings  of  two 
different  clocks  (a  real  and  a  virtual),  the  concept  of  synchronization  can  be 
defined  as  follows.  (We  assume  that  the  real  time  clocks  can  always  be  syn¬ 
chronized,  possibly  by  listening  to  an  external  timing  signal.) 

Definition 

We  say  two  stations  are  synchronized  iff 

1.  Their  virtual  clock  readings  are  the  same  and 

2.  Their  virtual  clocks  run  at  the  same  rate. 


The  question  arising  here  is  whether  or  not  the  stations  in  a  network  can 
be  synchronized  after  a  long  run  period  and  under  what  conditions. 

Let  us  first  consider  a  network  composed  of  two  stations  transmitting  unit 
length  messages  of  a  single  priority  class.  Let  the  propagation  time  between 
the  stations  be  a  <  1.  Also  assume  that  at  time  r0  the  stations’  virtual  clocks 
have  the  same  readings  (t*10  =  r'2 o)  and  started  running  at  common  rate  rj  (i.e., 
the  stations  were  synchronized)  (Figure  3.1). 

At  time  r !  station  1  transmits  a  message  and  stops  its  virtual  clock  at  read- 
ing  T’n.  Station  2  will  sense  the  message  after  time  a,  i.e.  at  time  t2  =  Tx+a, 
and  stop  its  virtual  clock  on  reading  r'21  =  -fn+rja  (  assuming  that  it  did  not 
catch  up  with  real  time  ).  At  the  end  of  the  message,  station  1  will  start  run¬ 
ning  its  virtual  clock.  When  station  2  senses  the  end  of  message  (after  time  a), 
both  virtual  clock  readings  will  be  T’u+?7a  =  r’2l.  At  that  time  the  stations  will 
be  again  synchronized. 

Another  way  of  seeing  the  above  is  by  watching  the  network  as  an  outside 
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Figure  3.1.  Successful  Transmission. 
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observer.  In  this  case  we  first  note  the  time,  r1(  that  the  transmission  from  sta¬ 
tion  1  began  .  After  r1(  the  channel  will  be  sensed  busy  at  station  1,  but  it  will 
continue  to  be  sensed  idle  at  station  2  for  a  further  time  a.  Up  to  time  Tj+a, 
the  difference  of  idle  channel  sensing  time  between  the  stations  is  a.  When  the 
tail  end  of  the  message  leaves  station  1,  at  time  r3,  the  channel  will  be  sensed 
idle  at  station  1,  but  it  will  continue  to  be  sensed  busy  at  station  2  for  a  further 
time  a.  The  difference  in  idle  channel  sensing  time  will  begin  decreasing  at  r3, 
and  will  be  zero  at  r3+a,  when  the  tail  reaches  station  2.  Thus  botli  stations  will 
have  sensed  the  channel  idle  for  the  same  time  period.  However  we  cannot  be 
sure  that  they  will  again  be  synchronized.  That  is  because  their  virtual  clocks 
may  not  run  at  the  same  rate  while  sensing  idle  channel.  (  Recall  that  in  the 
above  example  we  assumed  the  virtual  clock  at  station  2  did  not  catch  up  with 
real  time  while  sensing  idle  channel.) 

Figure  3.2  shows  a  worst  case  example,  namely  where  the  virtual  clock  at 
the  receiving  station  was  running  with  real  time  when  it  sensed  the  start  of  the 
message.  At  time  rlP  while  its  virtual  clock  reading  was  r’n,  station  1  started 
transmitting.  Station  2  sensed  the  message  after  time  a,  while  running  with 
real  time  and  stopped  its  virtual  clock  at  reading  r'22  =  r2  =  rl+a.  At  t3  =  Tt  +  1 
station  1  stopped  transmitting  and  started  running  its  virtual  clock  at  rate  77. 
Station  2  sensed  the  end  of  transmission  at  time  r4  =  r3+a  and  started  running 
its  virtual  clock.  Here  station  2’s  virtual  clock  reading  is  r'22  (  =  Ti+a)>  while 
station  l’s  virtual  clock  reading  is  r'14  =  r'n+r)a.  So  although  both  stations 
sensed  idle  channel  for  the  same  time  period,  they  are  not  synchronized.  The 
stations  will  again  be  synchronized,  when  station  2’s  virtual  clock  catches  up 

11  1 

with  real  time  at  time  r6  =  t4h - —  =  r3+a  + - — .  So  in  this  case,  time  a  +■  - — — 

rj-l  77-I  77-I 

is  needed  after  the  end  of  the  message,  before  the  stations  are  again  synchron¬ 
ized,  assuming  no  further  transmissions  occur  in  the  mean  time. 


From  the  above  discussion,  we  may  conclude  that  for  the  model  described 
above,  (assuming  that  the  stations  were  synchronized  at  the  beginning  of  the 
message  transmission,  and  no  other  transmissions  occurred  afterwards)  a  time 


period  between  a  and  aH - , 

77-I 


beyond  the  end  of  the  message  transmission, 


will  be  required  before  the  stations  regain  full  synchronization,  depending 
whether  the  receiving  station  was  running  beyond  or  with  real  time  when  it 
sensed  the  start  of  the  message. 


Before  we  continue  our  discussion,  we  must  describe  the  timing  of  a  sta¬ 
tion  during  a  collision.  When  a  collision  occurs  it  will  be  detected  by  the  station 
after  a  delay  of,  say,  d.  In  order  to  start  reacting  to  the  detected  collision  (i.e., 
set  its  electronic  circuits),  a  further  delay  of,  say,  s  will  take  place.  Finally, 
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Figure  3.2.  Successful  Transmission. 
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depending  on  the  backoff  algorithm,  a  delay  of,  say,  j  may  be  needed,  so  that 
the  station  to  stop  its  transmission  [33].  Since  the  total  delay,  from  the  time 
that  a  collision  occurred,  until  the  time  that  the  station  stopped  transmitting 
(i.e.,  the  sum  of  the  above  delays),  is  the  one  that  will  effect  the  network’s 
behavior.  We  define  it  as  collision  recovery  time  (r),  and  use  it  to  parameterize 
our  systems  in  the  following  discussions. 


Coming  back  to  our  initial  discussion,  Figures  3. 3-3. 4  show  examples  of  the 
virtual  clock  readings  when  a  collision  occurs  and  the  collision  'detection 
feature  exists,  in  the  cases  where  the  virtual  clocks  did  not  and  did  catch  up 
with  real  time,  respectively.  In  the  case  of  a  collision,  we  assume  that  the 
recovery  time  is  r  <  1  and  that  station  2  starts  transmitting  time  c  after  sta¬ 
tion  1,  where  c  <  a.  It  is  easy  to  see  that  in  the  first  case  (Fig. 3.3)  the  stations 


need 


7J-1 


time,  after  the  end  of  the  message  so  as  to  be  again  synchronized, 


2a  +7* 

while  in  the  second  (Fig. 3. 4)  they  need  - — -+c.  Note  that  in  the  case  of  a  col- 

7J-1 

lision  both  stations  sense  the  channel  to  be  idle  and  busy  for  the  same  time 
period,  while  the  first  transmits  for  (a+c)+r  and  the  second  for  (a-c)-Hr.  Thus 
the  stations  can  figure  out  who  was  really  first.  Note  that  this  is  true  only  when 
the  collision  was  due  to  exactly  two  stations. 


When  we  do  not  have  the  collision  detection  feature,  after  a  collision  the 
stations  will  be  again  synchronized  only  when  their  virtual  clocks  catch  up  with 
real  time.  Figures  3. 5-3.6  show  examples  of  a  collision  when  we  do  not  have  col¬ 
lision  detection.  If  d  is  the  first  station's  virtual  clock  difference  with  real  time 
when  a  message  started,  then  we  have  that  the  stations  will  be  resynchronized 
after 

l+a  +  2c  +  d  +  1't~a+2c  -  (l+a  +  2c)77  +  d 
77-I  77-I 

from  the  moment  that  the  first  message  ended,  when  the  first  station’s  virtual 
clock  catches  up  with  real  time.  That  means  that  the  time  until  the  stations 
are  resynchronized  again,  can  be  arbitrarily  long,  depending  on  the  initial 
difference  of  their  virtual  clock  with  real  time.  Note  that  in  this  case  although 
both  stations  are  transmitting  for  the  same  time  (  unity  ),  they  sense  busy 
channel  for  different  time  periods.  In  fact  the  first  station  sense  busy  channel 
time  2c  longer  that  the  second.  It  is  also  interesting  to  notice  that  in  the 
above  formula  the  state  of  the  second  station’s  virtual  clock,  i.e.  whether  is  was 
running  beyond  or  with  real  time,  does  not  affect  the  resynchronization  time 
period. 


Define  a  message  epoch  to  be  the  time  from  the  moment  that  a  message 
first  appears  in  the  channel,  until  the  moment  where  both  stations  are  again 
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Figure  3.3.  Collision. 
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Figure  3.5.  Collision  without  Collision  Detection. 
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synchronized,  assuming  that  no  other  messages  appear  in  the  channel,  except 
possibly  for  colliding  ones.  Then  we  have  Table  3.1  for  the  length  of  a  message 
epoch.  (Note  that  0<c<a.) 


Successful  transmission 
Collision  with  collision  detection 

Collision  without  collision  detection 


Second  station's  virtual  clock 
beyond  real  time  with  real  time 

1  +  a 


2a  4-rH — 2a 
77“1 

x  ,  (l+a+2c)77 
rj-1 


+r  +c  +t 

+  d. 


2a  +r 
r)-l 


Table  3.1  Message  epoch  length. 

It  is  easy  to  observe  from  Figures  3.1  to  3.6  that  the  difference  in  the  virtual 
clock  readings  of  the  two  stations  is  always  less  than  2r)a.  This  is  the  maximum 
difference  that  we  can  observe  for  the  two  stations’  virtual  clocks,  over  any 
message  epoch,  provided  no  message  epochs  overlap.  Even  more  in  the  case 
where  we  have  collision  detection,  this  is  the  maximum  difference  over  any 
time  period.  This  is  almost  obvious  since  both  stations  will  sense,  over  a  long 
period  of  time,  the  channel  to  be  busy  and  idle  for  the  same  fraction  of  time 
and  the  differences  in  the  virtual  clock  readings  are  due  to  transient  states, 
like  the  beginning  and  end  of  a  message,  which  need  time  2a  so  as  to  propagate 
through  the  channel  [  1 1] . 


Let  us  now  examine  the  case  where  the  message  epochs  overlap  each 
other. 


Definition 

We  define  a  K-message  epoch  to  be  the  time  period  passed  from  the 
moment  when  the  first  of  K  messages  started,  until  the  moment 
where  the  stations  are  resynchronized  again  for  the  first  time. 


We  first  assume  a  collision  free  channel.  Since  the  message  epochs  overlap 
each  other,  we  can  assume  that  after  the  first  transmission  (in  the  beginning  of 
which  the  stations  were  synchronized)  some  of  the  virtual  clocks  will  have  a 
backlog.  That  means  that  we  have  two  distinct  cases  when  the  stations'  virtual 
clocks  in  the  initial  transmission  did  and  did  not  catch  up  with  real  time.  In 
the  case  where  the  stations  did  not  catch  up  with  real  time,  things  are  simple. 
Figure  3.7  gives  an  example.  (Note  that  because  we  have  assumed  a  collision 
free  channel,  if  the  stations  did  not  catch  up  with  real  time,  then  we  have  over¬ 
lapping  epochs  only  when  the  transmissions  are  from  the  same  station).  It  is 
easy  to  observe  that  no  matter  of  the  history  of  the  transmissions,  the  stations 
need  time  a  after  each  transmission  so  as  to  resynchronize.  Assuming  that  a 
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Figure  3.7.  K-message  epoch. 
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new  message  will  be  transmitted  time  ct  after  the  end  of  the  ith  message 
(where  i  =  1,2 . K— 1),  the  A'-message  epoch  length  will  be 

K  +  ^  ct  +  a  (3.1.1) 

i  =  l 


Now  consider  the  case  where  some  stations'  virtual  clocks  were  running 
with  real  time  at  the  beginning  of  the  transmissions.  The  worst  case  will  be 
when  the  new  transmissions  occur  just  before  the  stations  resynchronize  (Fig¬ 
ure  3.8)  from  either  one  of  the  stations.  In  this  case  the  total  epoch  length  will 
be 


Jfx(l+a  +  -±-)  =  K-P-  +  Ka 

77  —  1  77—1 


(3.1.2) 


where  l  +  a+  i-s  message  epoch  length  for  successful  transmission,  with 
the  second  station’s  virtual  clock  running  with  real  time,  as  given  by  table  3.1  . 


On  the  other  hand  the  best  case  will  be  when,  after  the  first  transmission,  all 
stations’  virtual  clocks  have  a  backlog.  In  this  case  we  must  consider  two 
extreme  possibilities:  the  first  when  only  one  station  is  transmitting,  and  the 
second  when  both  stations  are  transmitting  alternately.  Figures  3.9-3.10  illus¬ 
trate  the  above  extreme  cases,  respectively.  Obviously  the  stations  will  be 
resynchronized  (in  both  cases)  only  when  they  both  catch  up  with  real  time. 


When  only  one  station  is  transmitting  (Fig. 3. 9)  the  channel  will  be  idle  for 

time  Ci  after  each  (successful)  transmission  and  the  stations’  virtual  clocks  will 

increase  by  770*.  Without  loss  of  generality  we  cam  assume  that  at  the  beginning 

of  the  burst,  real  time  was  0  and  the  virtual  clock's  readings  were  also  0,  for 

both  stations.  At  the  end  of  the  Klh  message  transmission,  station  l’s  (the 

K- 1 

transmitting  station’s)  virtual  clock  readings  will  be  ^  0*77  while  station  2’s  will 

i  =  1 

be£  0*77  +  a  .  At  that  moment  real  time  is  K  +  ^  c*  .  Station  2  will  sense  idle 


i  =  1 


K- 1 


channel  at  time  K  +  ct  4-  a  and  catch  up  with  real  time  after  a  further  time 

i  =  l 


of 


K 


^  ciV  +  a 

i  =  \ 

K- 1 


K 


,-1  =-S,c‘  +  Fr 

So  in  this  case  the  if-message  epoch  will  last 

K  +  a  -^ci  +  -3j-  =  +  a  = 

i  =  l  i  =  l  1  1  1 


=  K^—+  a 
77-I 


(3.1.3) 
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Figure  3.8.  K-inessage  epoch. 
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Figure  3.9.  K-message  epoch.  (First  extreme  case) 
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Figure  3.10.  K-massage  epoch.  (Second  extreme  case) 
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Note  that  the  values  of  c*  have  no  effect  in  the  epoch's  length. 

In  the  case  where  the  stations  are  alternately  transmitting  (Fig. 3. 10),  with 
similar  assumptions  as  above,  we  have  that  station  2  will  sense  the  end  of  the 
/fth  message,  at  reed  time 


K  + 


K+  1 


K- 1 

“  +  E  Ci 

i  =  1 


while  its  virtual  clock  reading  will  be 


a  +  rj 


jc^  4-  a  (i  mnri  2)| 


and  will  catch  up  with  real  time,  signifying  the  end  of  the  epoch,  after  time 


K  + 

K+  1 

O 

a  4-  ct  -a  +77 

+  a  (l  mnrl  2)] 

c 

i  =  l 

i  =  l 

l  ) 

77-I 

So  the  total  /^-message  epoch  length  will  be 


K  + 


K+  1 


K- 1 

a  +  Yj  ci 

i  =  1 


K  4 - 

K+  1 

K- 1 

a  4-  ci“ 1 a  +  V 

K- 1 

S 

Ci  +  a  (i  moH  2) 

p 

C 

i  =  l 

i=l 

77-1 


Finally  we  have  the  /f-message  epoch  length  to  be 


K 


77-I 


4-  a 


(3.1.4) 


A  summary  of  the  above  results  for  the  /f-message  epoch  length,  is  given  in 
table  3.2  . 


Second  station's  virtual  clock 
in  initial  transmission. 

min 

max 

beyond  real  time 

K- 1 

K  4-  Yj  ci  +  a 

i  =  l 

with  real  time 

KJ1—+  a 

4-  Ka 

77-I 

77-I 

Table  3.2  A'-message  epoch  length. 


From  Tables  3.1,  3.2  we  see  that  the  message  epoch  length  is  well  defined 
in  every  case  and  so  the  stations  can  make  use  of  this  information  in  order  to 
obtain  better  performance  characteristics,  as  it  will  be  discussed  in  the  next 
sections. 
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3.2.  The  FCFS  discipline. 

One  the  features  of  the  VT-CSMA  protocol  is  that  it  preserves  the  FCFS  dis¬ 
cipline.  Obviously  this  is  true  for  messages  arriving  from  a  specific  station,  but 
it  may  not  be  true  for  messages  arriving  from  different  stations,  unless  a  high 
degree  of  synchronization  among  the  stations  is  maintained. 

In  the  previous  section,  we  showed  for  the  two  station  bus  model  with  colli¬ 
sion  detection  that  the  difference  in  the  virtual  clocks  of  the  stations  will  never 
exceed  2t)cl.  As  a  result  to  this,  the  FCFS  discipline  will  always  be  served  and 
any  attempt  to  reverse  it  will  lead  to  a  collision.  Unfortunately  this  is  not  true 
when  more  than  two  stations  access  the  channel.  As  a  simple  example  for  this, 
consider  a  network  with  three  stations  in  line  equally  spaced  (Figure  3.11). 
Suppose  that  the  two  stations  at  the  ends  of  the  line  were  to  start  transmitting 
a  message  at  exactly  the  same  moment.  Then,  at  the  end  of  the  collision,  these 
two  stations  will  have  sensed  the  channel  to  be  busy  for  2a  and  collide  for  r, 
while  the  middle  station  will  sense  the  channel  to  be  busy  for  zero  time  and  col¬ 
lide  for  a  +r  (Figure  3.12).  So  the  middle  station  will  sense  idle  channel  longer 
than  the  other  two  stations. 

If  now  the  arrival  rate  is  high  enough,  so  that  the  message  epochs  overlap, 
and  the  network  is  not  balanced  (i.e.  the  load  offered  from  the  stations  is  not 
the  same  (*)),  then  the  difference  in  the  idle  channel  sensing  time  produced  by 
the  collisions  will  accumulate  and  there  is  a  possibility  for  the  middle  station  to 
be  indefinitely  ahead  of  the  other  two  stations.  Obviously  this  type  of  situation 
will  lead  to  a  discrepancy  with  the  FCFS  discipline. 

As  a  simple  example  consider  the  above  3  station  network  working  with  a 
collision  resolution  algorithm  such  that  whenever  a  collision  occurs,  one  of  the 
stations  will  retransmit  its  message  immediately  when  it  senses  idle  channel 
for  the  first  time,  the  other  when  it  senses  idle  channel  for  a  second  time,  etc. 
(Simply  a  tree  algorithm  working  in  an  optimal  way.)  Assuming  that  for  a  long 
time  period  only  stations  1  and  3  are  transmitting,  the  total  time  until  two  col¬ 
liding  messages  are  successfully  transmitted  will  be  2a +r  +2(a  +  l),  assuming 
that  both  stations  started  at  the  same  moment.  In  a  worst  case  analysis,  all 
messages  will  collide  once  before  being  successfully  transmitted.  This  way  we 
obtain  periodic  transmission  cycles  of  a  collision,  with  length  2a +r,  followed  by 
two  successful  transmissions  of  length  a  +  1.  During  each  cycle,  stations  1  and  3 

(  )  The  idea  of  having  an  unbalanced  network  is  not  unrealistic.  There  exist  networks  where 
a  group  of  stations  transmit  packets  on  a  specific  priority  class,  while  other  station  groups 
transmit  in  different  (higher  or  lower)  priority  classes  and  each  priority  class  has  a  different 
arrival  rate. 


-26- 

-27- 


a/2  a/2 

- — - - »-— ■ - « 

Figure  3.11.  3 -Station  Bus  Network 


Figure  3.12.  Channel  sensing  for  the  3-station 
network,  when  a  collision  occurs. 
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(the  transmitting  stations)  will  sense  idle  channel  for  time  3a,  while  station  2 
will  sense  idle  channel  for  4a.  A  reasonable  assumption  for  the  above  is  that 
the  virtual  clocks  of  the  stations  will  always  have  a  backlog.  After  K  cycles  the 
real  time  will  be 

T  =  ifx[2a+r+2(a  +  l)]  (3.2.1) 

while  the  virtual  clock  readings  of  the  stations  will  be 


Station  1,3  KxSay 
Station  2  Kx^ay 


A  message  arriving  at  that  moment  at  station  1  or  3,  will  be  transmitted  when¬ 
ever  the  station’s  virtual  clock  readings  become  T.  That  will  be  after 
T~Kx3ay  T 
Say  3  ay 

T 


K  cycles,  while  the  real  time  will  be 
T  +  — —  K  x  [2a  +t  +  2(a  +  l)]  = 


Say 


"—"X  [2a+r+2(a  +  l)] 


(3.2.2) 


A  message  arriving 
T+B-Kx 4ay  _  T+B 
4a?}  4a?7 


at  station  2  after  time  B,  will  be  transmitted  after 
—K  cycles,  at  real  time 


T+B  + 


T+B 

4ay 


x  [2a +r  +2(a  +  l)]  = 


T+B-x  [2a+r-f-2(a  +  l)l 
4a77 


Comparing  (3.2.2)  and  (3.2.3)  we  finally  have  that 


iff 


^  x  [2a +7’+2(a +  l)]  >  ~~~x  [2a +r +2(a +l)] 


3a77 


4a?] 


T  T6 
B  <  3+  12  Ka 


(3.2.3) 


(3.2.4) 


So  a  message  arriving  at  station  2  after  time  B  from  a  message  arriving  at 
either  station  1  or  3,  will  be  transmitted  before  the  message  from  station  1  or  3 
do.  That  problem  would  be  easily  resolved  if  we  could  use  the  synchronization 
results  found  in  the  previous  section.  But  that  implies  knowledge  of  the  net¬ 
work  topology  (because  the  propagation  time  among  the  stations  is  required). 
Some  ideas  on  that  will  be  presented  in  the  next  section. 


On  the  other  hand  if  the  network  is  not  overloaded  and  the  traffic  is  well 
balanced,  the  difference  in  the  virtual  clocks  readings  will  remain  finite  and  the 
FCFS  discipline  will  be  served  for  groups  of  messages  (where  each  group  will 
contain  all  messages  with  interarrival  time  less  than  a  specific  value). 
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The  situation  described  above  does  not  apply  by  any  means  to  the  slotted 
protocol.  In  the  slotted  protocol  the  only  difference  which  appears  is  in  the 
exact  time  of  the  slot’s  start.  This  difference  is  fixed  and  meaningless,  since 
the  slot  size  is  greater  than  the  end  to  end  propagation  time  and  therefore  all 
stations  can  identify  identically  the  status  of  each  slot,  and  count  the  same 
number  of  idle,  collide  and  busy  slots. 


3.3.  The  network  topology. 

In  the  previous  section  we  saw  that  the  position  of  a  station  in  an  unslotted 
network  is  critical.  Here  we  will  discuss  how  the  network  topology  can  affect 
the  characteristics  of  a  protocol  and  whether  the  exact  knowledge  of  the  net¬ 
work  topology  has  anything  to  offer. 

In  the  example  of  the  three  station  network  from  the  previous  section,  we 
saw  that  the  middle  station  senses  idle  channel  longer  than  the  other  two  when¬ 
ever  transmissions  from  the  outside  stations  collide.  That  problem  can  be 
resolved  if  we  introduce  a  protocol  in  which  the  stations  will  consider  the  chan¬ 
nel  to  be  busy  for  an  additional  time  period  alter  a  collision,  even  if  it  is  actu¬ 
ally  idle.  To  determine  that  time  period,  the  stations  must  have  exact 
knowledge  of  the  network  topology.  As  an  example,  consider  a  stair  network 
where  every  station  is  the  same  distance  from  the  "hub"  (where  there  is  no  sta¬ 
tion)  (Figure  3.13).  Thus  the  propagation  time  between  any  pair  of  stations  is 
fixed  at  a.  Assume  that  4  of  the  stations  are  involved  in  a  collision.  Table  3.3 
shows  the  channel  status,  as  sensed  by  the  stations. 


St.l 

St.  2 

St. 3 

St. 4 

St.  5 

time 

B 

I 

I 

I 

I 

771  j 

B 

B 

I 

I 

I 

771 2 

B 

B 

B 

I 

I 

771 3 

B 

B 

B 

B 

I 

771 A 

B 

CP>* 

C(2)' 

C(2)' 

B 

a  +771 ! 

c<2>* 

c<2>* 

CP>' 

c<3>' 

C(1) 

a  +771 2 

C<3>* 

c<3>* 

C(3)’ 

c(4)# 

C(3) 

a  +771 3 

c(4)# 

C(4)* 

C(4)' 

C(4)* 

C(4) 

a  +771 4 

C(4)' 

C(3) 

C(3) 

C(3) 

c(4) 

a  +77i!+r 

C(3) 

C(3) 

CP) 

C(3) 

c(4) 

a  +77ip+r 

I 

B 

B 

B 

B 

2a+77i1+r 

I 

I 

I 

I 

I 

2a  +77ip+r 

771 2  ””771  j 

771  g  771  j 

771 3 — 771  j 

771 4— 771  j 

a 

Table  3.3  Star  network,  collision  channel  sensing. 
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Figure  3.13.  Equally  spaced  star  network. 


-31  - 


Chapter  3.3. 


For  easier  understanding  of  the  table,  with  we  denote  a  collision  due  to  i 
stations  and  with  C*  a  collision  while  the  station  is  transmitting.  Obviously  a 
station  cannot  discriminate  between  the  types  of  collisions  appearing  in  the 
table  and,  even  more,  after  a  collision  it  can  only  sense  whether  the  channel 
state  is  idle  or  collide.  So  the  busy  channel  sensing,  appearing  after  the  colli¬ 
sion  in  the  table,  is  only  for  notational  reasons  and  cannot  be  detected  by  the 
station.  The  last  line  in  the  table,  gives  the  total  idle  channel  sensing  time  of 
each  station,  encountered  from  the  moment  that  the  first  message  appeared  in 
the  channel,  up  to  the  moment  where  all  stations  sensed  idle  channel. 

Fact: 

All  stations  in  the  above  star  network  know  exactly  what  was  the  addi¬ 
tional  time  that  they  sensed  idle  channel  and  whether  they  were  the 
first  to  transmit. 


Proof. 

Without  loss  of  generality,  we  can  number  the  stations  in  order  of  starting 
to  transmit. 

Each  of  the  stations,  say  station  i,  can  record  the  following  times: 

1.  the  time  B*  that  it  first  sensed  the  channel  busy, 

2.  the  time  C*  it  detected  the  collision,  and 

3.  the  time  U  it  again  sensed  idle  channel. 

Also  the  stations  know  the  (constant)  propagation  time  a  and  the  recovery 
time  r . 

Since  a  is  the  propagation  time,  any  message  appearing  on  the  channel 
will  be  sensed  from  the  other  stations  after  time  a.  Thus,  the  message 
transmitted  from  the  second  station  will  be  sensed  by  the  other  stations 
after  a.  In  the  case  of  the  first  station,  sensing  the  second  station’s  mes¬ 
sage  will  inform  it  that  a  collision  is  taking  place,  and  because  the  first  sta¬ 
tion  started  before  the  second  we  have  that 

Cj  -  B!  >  a 

The  message  transmitted  from  the  first  station  will  have  propagate  for  a 
fraction  of  the  propagation  time  when  any  of  the  involved  stations  start 
transmitting.  This  way  the  other  stations  will  sense  station  l’s  message  in 
less  than  a  full  propagation  time  from  the  moment  they  started  transmit- 
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ting.  The  moment  they  will  sense  it  they  will  also  identify  the  collision. 
Thus 

Ci  -  Bi  <  a  i=  2,3... 

Figures  3.14a-e  illustrate  the  above.  So  each  station  knows  whether  or  not 
it  was  the  first  to  transmit.  The  first  transmitting  station  also  knows  when 
the  second  station  started  transmitting,  namely  at 

B2  =  C!-a  (3.3.1) 

The  other  stations  involved  in  the  collision  also  know  when  the  first  sta¬ 
tion  started  transmitting,  that  is 

Bi  =  Ci  -  a  (3.3.2) 

All  stations,  except  the  first,  will  stop  transmitting  exactly  at  the  same 
time  (namely  at  Bi+a+r),  while  the  first  station  will  stop  later  than  the 
others,  at  Bg+a+r,  since  it  was  the  last  to  sense  the  collision.  Thus 
between  times  Bj+a+r  and  Bg+a+r,  only  the  first  station  is  transmitting  a 
message.  Since  any  message  transmitted  by  one  station  reaches  the  other 
stations  after  time  a,  all  stations  except  station  1  will  change  their  chan¬ 
nel  sensing  from  busy  to  idle  at  the  exactly  the  same  time,  namely  at  time 
a  after  station  1  stops  transmitting.  Thus,  for  these  stations, 

1^  =  (i?2  +  a+  r)  +  a 

B2  =  Ii“(2a+r)  (3.3.3) 

Finally  the  stations  that  remained  silent  also  know  when  the  first  and 
second  stations  transmitted; 

Bi  =  B  -a  (3.3.4) 

B2  =  I  -  (2a  +r )  (3.3.5) 

So  every  station,  say  station  i,  knows  times  B*.  Of,  If  and  also  Blt  Ilt  B2l  and 
I2.  Note  that 

li  =  Bi  +  2a  +r 

and 

I2  =  B2  +  2a  +  r  =  If  ( when  i/1) 

As  a  result,  it  knows  how  much  additional  time  it  sensed  idle  channel  com¬ 
pared  to  the  first,  second  and  non-involved  stations.  That  is 
from  the  first: 

Bf  — Bj  —  ( If  —  Ii)  -  (wheni^l) 

Bf— Bi-(Bf— Bg)  =  Bf-B2 

from  the  second 

Bf -B2  wheni^l 
0  when i = 1 

and  from  the  non-involved 
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Figure  3 . 14 . a  The  First  station  start 

transmitting  (time  mi)  . 


1 


Figure  3.14.b  The  Second  station  start 

transmitting  (tine  m2)  . 
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Figure  3.14.C  The  Third  station  start 

transmitting  (time  m3 ) . 


1 


5 
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Figure  3.14.d  The  stations  sense  the  first 

station's  message  (time  mi+2a) . 


-35- 

1 


Figure  3.14.e  The  stations  sense  the  second  station's 

message.  All  stations  identify  the  collision, 
(time  m2+2a)  . 
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Bi  —  ( Bi  +  a  )  when  i  *  1 
B2-(B,  +  a)  when  i  =  1 

One  thing  to  note  is  that  the  first  and  second  stations  ignore  the  existence 
of  the  other  involved  stations.  Also  note  that  their  channel  sensing  is 
same,  as  it  may  have  been  expected  since  the  ignorance  of  the  other  col¬ 
lide  stations,  makes  them  identify  the  collision  as  a  two  station  collision, 
and  therefore  follow  the  timing  described  in  section  3.1  (Figure  3.3). 

110 


With  the  knowledge  of  the  additional  idle  channel  sensing,  all  stations  can 
pretend  the  channel  to  be  busy  for  some  time  period  after  the  collision,  and 
synchronize  with  the  rest  in  a  minimum  time.  In  the  previous  five  station 
example,  stations  1  and  2  will  assume  the  channel  to  be  busy  for  no  additional 
time  (obviously,  since  they  do  not  know  the  existence  of  other  stations  involved 
in  the  collision),  stations  3  and  4  for  Bt-B2  and  station  5  for  a— (B2-B!).  This 
way  the  stations  will  be  completely  synchronized  a  time  units  after  the  end  of 
the  first  station’s  transmission. 

These  results  also  allow  us  to  resolve  a  collision  for  "free",  since  the  first 
and  second,  stations  know  that  they  are  the  first  and  second,  while  the  others 

know  that  they  are  no  earlier  than  third  with,  possibly,  some  other  stations.  So 

\ 

a  collision  due  to  up  to  three  stations  can  be  resolved  for  free. 

The  above  results  can  be  extented  to  any  star  network,  if  we  let  each  sta¬ 
tion  simulate  the  actions  of  another  station,  located  further  from  the  hub  on 
the  same  branch,  and  all  of  these  simulated  stations  are  the  same  distance 
from  the  hub.  A  similar  algorithm  can  be  used  to  keep  the  simulated  stations 
synchronized.  Figure  3.15  is  an  example  of  such  a  network.  The  real  stations 

are  numbered  as  1,2,3...;  while  the  simulated  stations  are  numbered  l',2',3' . 

What  the  stations  need  to  know  in  such  a  network,  is  the  propagation  time 
between  the  simulated  stations,  the  recovery  time  and  their  distance  from  the 
corresponding  simulated  station  (d*).  A  transmission  from  a  real  station,  say 
station  i,  can  be  seen  to  be  equivalent  to  a  transmission  from  a  simulated  sta¬ 
tion  which  happened  at  time  d*  earlier.  Also  a  message  received  at  a  real  sta¬ 
tion  will  be  sensed  at  the  corresponding  simulated  station  at  time  d*  later. 
Thus  all  stations  know  exactly  the  status  of  their  simulated  station,  and  can 
calculate  the  above  results  for  the  simulated  stations.  The  advantage  of  this 
strategy  can  be  seen  from  the  following  points.  Since  the  simulated  station 
knows  that  a  message  will  be  received,  before  it  actually  receives  it,  it  can 
delay  any  message  transmissions  that  would  lead  to  definite  collision.  This  way 
we  can  reduce  the  number  of  collisions.  On  the  other  hand,  since  the  real  sta¬ 
tion  is  the  one  that  actually  transmits  messages,  it  can  start  transmitting  as 
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Figure  3.15.  Star  network  with  simulated  stations. 


-38- 


Chapter  3.3. 


soon  as  it  senses  the  channel  to  be  idle.  That  means  that  the  simulated  station 
would  be  able  to  transmit  a  message  before  it  sense  idle  channel  and  without 
causing  a  collision,  and  thus  increasing  the  channel  utilization.  (Note  that  in 
the  last  case,  the  real  stations  do  not  lose  synchronization  with  the  simulated 
ones,  because  the  idle  channel  sensing  is  for  both  stations  zero.)  One  thing  that 
we  must  make  note  of,  is  that  the  epochs,  in  this  case,  will  overlap.  If  the  sta¬ 
tions  simply  ignore  this  overlaping  and  "forget"  all  the  epochs  which  ended  at 
any  time  in  the  past,  the  above  results  also  apply  for  the  simulated  stations 
(i.e.,  station  synchronization,  free  collision  resolution  etc.).  So  we  can  say  that 
an  equally  spaced  star  network  is  a  worst  case  example  over  all  unequally 
spaced  star  networks,  with  shorter  or  equal  branches. 

In  the  bus  network  topology,  things  are  getting  more  complicated  and  the 
above  strategy  holds  only  partially. 

Assume  a  5  station  bus  network,  with  unequally  spaced  stations,  and  let  a* 
be  the  propagation  delay  distance  of  station  i  from  the  one  end  of  the  bus  (it 
makes  no  difference  which  end  we  choose,  as  long  as  it  will  be  the  same  for  all 
stations).  The  stations  can  sense  times  ES*.  C*  and  I*  as  described  above.  First 
of  all  it  is  clear  that  in  a  successful  message  transmission,  none  of  the  stations, 
except  the  one  actually  transmitting,  can  calculate  the  message  transmission 
time  (because  they  do  not  know  their  distance  from  the  transmitting  station). 
Consider  now  the  case  of  a  collision  due  to  two  stations.  Figure  3.16  gives  the 
time  diagram  of  a  two  station  collision. 

Fact: 

Knowing  that  a  collision  was  caused  by  only  two  stations,  only  the  two 

involved  stations  know  the  exact  timing  of  the  network. 


Proof, 

Let  k  and  L  be  the  collide  stations,  where  either  one  of  them  can  be  the 
first  to  transmit.  Station’s  k  message  will  propagate  through  the  channel 
and  sensed  by  the  other  stations  at  time 

+  |  a*  -at  | 

That  is,  station  l  will  sense  the  collision  at  time 

C i  —  B k  +  |  ci-ic  —  o-i  |  (3.3.6) 

sind  recover  at  time  ct+r. 

The  recovery  of  station  l  (the  end  of  transmission)  will  propagate  end 
sensed  by  the  other  stations  at  time 
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Figure  3.16.  Collision  in  a  bus  network. 

Stations'  channel  sensing. 


4 


5 
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Ct+r+lat-Oil 

where  in  the  case  of  station  k ,  that  will  be  the  time  that  it  will  sense  idle 
channel. 

I*  =  Ci  +r  +  |  Of  -ak  i  (3.3.7) 

From  (3.3.6)  and  (3.3.7)  we  have  that 

I*  =  Bfc+r+Slai-cifc  |  (3.3.8) 

So  station  k  knows  its  absolute  distance  from  station  l  (the  other  transmit¬ 
ting  station),  and  therefore  it  can  uniquely  identify  it  (there  is  a  case  of 
symmetric  stations,  but  if  the  stations  can  sense  the  direction  of  a  pro¬ 
pagating  message,  the  problem  can  be  resolved).  With  the  identification  of 
the  other  transmitting  station,  station  k  can  from  (3.3.6),  modified  for  the 
message  from  station  l  to  C*  =Bi  +  |af—  ak\,  calculate  the  transmission 
time  Bl  and  thus  the  timing  of  all  the  network.  For  the  other  stations, 
finding  which  were  the  colliding  stations  is  almost  impossible.  That  is 
because  they  will  have  first  to  guess  one  of  the  transmitting  stations  and 
then  try  to  match  their  channel  sensing  with  the  possible  transmission  of 
an  other  station.  But  this  can  give  them  more  than  one  possible  pair  of 
transmitting  stations,  depending  on  the  network  and  their  channel  sens¬ 
ing. 
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So  even  when  we  know  that  a  collision  in  a  bus  network  was  due  to  two  mes¬ 
sage  transmissions,  we  do  not  have  a  deterministic  method  giving  to  all  stations 
the  necessary  information  for  them  to  resynchronize  with  the  other  stations  in 
a  minimum  time  following  a  collision.  Even  more,  there  is  no  method  for  any 
station  to  determine  whether  or  not  a  collision  was  due  to  two  or  more  message 
transmissions,  in  an  unambiguous  way.  Therefore  since  we  cannot  use  deter¬ 
ministic  methods  in  a  bus  network,  probabilistic  ones  have  to  be  used.  A  dis¬ 
cussion  on  that  can  found  in  [11].- 

A  conclusion  of  the  above  discussion  is  that  in  the  star  network,  due  to  its 
special  structure,  certain  optimizing  methods  can  be  used  that  cannot  be 
applied  in  a  bus  network.  Those  types  of  methods  lead  to  some  kind  of  "slot¬ 
ting"  in  which  although  the  end  of  a  "slot"  is  well  defined,  the  stations  do  not 
have  to  wait  an  integer  number  of  slots  before  starting  to  transmit,  but  cam 
transmit  at  any  time  after  they  sense  idle  channel.  This  way  we  gain  the  time 
of  the  otherwise  idle  slots,  at  the  end  of  a  transmission.  Since  we  know  that 
slotted  protocols  behave  better  than  unslotted,  we  can  expect  an  improvement 
to  the  network  parameters.  A  problem  of  course  will  be  the  fact  that  calcula¬ 
tions  will  become  very  complicated  as  network  size  increases. 


Chapter  4. 
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4.  On  Simulating  the  Virtual  Time  CSMA  Protocol. 

As  mentioned  in  chapter  two,  the  original  analysis  of  the  virtual  time  CSMA 
protocol  [23]  was  mainly  concerned  with  the  slotted  version  of  the  protocol. 
This  analysis  also  contained  several  unrealistic  assumptions  to  make  the  model 
solvable.  Since  the  unslotted  version  of  the  protocol  is  of  greater  practical 
interested  than  the  slotted  version,  and  since  unslotted  protocols  are  even 
harder  to  model  accurately  than  slotted  protocols,  a  detailed  *study  of  the 
unslotted  protocol  can  only  be  performed  with  a  simulation  program. 

The  first  step  in  solving  a  problem  is  to  obtain  an  in  depth  understanding  of 
the  problem  and  describe  it  in  a  formalistic  way.  In  our  case,  the  network  to  be 
simulated  had  to  be  described  in  detail  in  order  to  obtain  the  exact 
specifications  of  the  simulation  program.  In  this  chapter,  the  target  network 
model  is  described  in  detail,  setting  the  program  specifications,  and  major  con¬ 
siderations  and  implementation  aspects  are  discussed. 

4.1.  The  Target  Network. 

A  local  area  network,  operating  under  the  VT-CSMA  protocol,  will  have  to 
use  some  backoff  algorithms  in  order  to  resolve  collisions.  Selection  of  the 
backoff  algorithms  is  the  main  objective  of  this  research.  In  the  following  we 
will  assume  existence  of  some  backoff  algorithms  without  being  concerned  of 
its  function. 

The  network  under  discussion  can  be  described  as  a  broadcast  network. 
That  is,  when  one  station  transmits,  all  other  stations  will  become  aware  of  it, 
after  the  signal  has  propagated  to  them.  A  broadcast  network  can  be  either  a 
radio  or  a  bus,  or  even  of  some  other  special  topology,  as  for  example,  a  star.  It 
can  obviously  be  uniquely  defined,  if  the  distances  between  the  stations  are 
given.  Assuming  that  the  medium  is  isotropic,  the  propagation  delays  among 
the  stations  can  be  equivalently  used.  In  broadcast  networks,  the  status  of  the 
channel  is,  in  general,  different  for  each  station.  This  is  obviously  due  to  the 
finite  propagation  delay  among  stations  (#).  Thus,  in  general,  any  change  in  the 
channel  will  be  sensed  by  the  stations  at  different  moments. 


(*)  At  this  point  the  major  difference  between  slotted  and  unslotted  protocols  shows  up. 
That  is,  although  under  a  slotted  protocol  all  stations  will  have  different  sense  of  the  chan¬ 
nel,  the  slot  status  will  be  identically  defined  from  all  stations  and  thus  there  is  no  need  to 
be  concerned  with  transient  differences  between  stations.  On  the  other  hand,  in  unslotted 
protocols,  the  transient  status  of  the  channel  will  affect  the  behavior  of  the  station  and  in 
consequence  of  the  whole  network. 
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In  the  independent  station  level,  we  can  obtain  a  very  good  description  of 
its  operation  if  we  view  the  station  as  a  union  of  independently  operating 
modules.  In  Figure  4.1  the  block  diagram  of  the  station  is  given,  and  in  the  fol¬ 
lowing  we  explain  its  basic  operation.  Since  the  network  is  carrier  sense,  a 
sensing  module  will  check  the  status  of  the  channel  and  issue  an  appropriate 
message.  This  will  be  received  by  the  module  handling  the  virtual  clocks,  which 
will  enable  or  disable  them  (i.e.,  if  the  channel  is  idle,  the  virtual  clocks  will  be 
enabled  to  run  towards  the  real  time,  while  if  it  is  busy,  they  will  6e  disabled.). 
The  readings  of  the  virtual  clocks  will  be  received  by  a  module  which  will,  by 
checking  the  queues  of  the  messages,  enable  the  first  in  a  queue  for  transmis¬ 
sion,  when  the  corresponding  virtual  clock  reading  equals  its  transmission  time 
(').  On  the  other  hand,  a  generation  module,  providing  the  system  with  new 
messages,  will  place  the  new  messages  in  an  appropriate  position  in  the  station 
queues.  Finally,  a  collision  module  will  reschedule  the  collided  messages  for 
retransmission  and  place  them  into  the  queues. 

A  completely  separate  module  will  be  the  receiver  at  the  station.  The 
receiver's  operation  is  not  so  well  defined,  but  it  will  be  the  one  that  will  decide 
whether  a  message  transmitted  by  the  station  will  collide  and  inform  the  colli¬ 
sion  module  for  rescheduling. 

Since  the  station  will  operate  using  electronic  circuits,  the  interaction  and 
information  exchange  time  between  the  modules  will  be  finite  and  thus  small 
delays  will  appear,  In  general,  delays  due  to  interaction  between  the  channel 
sensing,  virtual  clocks  enabling,  and  the  message  transmissions  will  be  very 
small,  so  that  they  will  not  change  the  toted  behavior  of  the  system.  On  the 
other  hand,  because  the  receiver  will  have  to  process  the  data  received,  in 
order  to  decide  whether  they  are  valid  or  not,  collision  detection  may  take 
some  time.  The  time  needed  will  obviously  depend  on  the  method  followed.  One 
method  would  be  the  receiving  station  having  to  sent  an  acknowledgement  to 
the  transmitting  station.  This  way,  a  collision  will  be  identified  long  after  the 
end  of  the  message  transmission.  One  other  is  having  the  transmitting  station 
check  whether  the  message  on  the  channel  matches  the  one  that  it  is  transmit¬ 
ting.  This  way  the  station  can  identify  a  collision  within  only  a  few  collide  bits. 
In  the  first  case  we  say  that  there  is  no  collision  detection,  while  in  the  second 
that  there  is. 

All  the  above  also  define  the  program  specifications  in  some  relevant 

( *).  Remember  that  we  are  concerned  with  the  unslotted  network  and  that  we  are  talking 
in  terms  of  multiple  priority  classes.  Also  we  must  bear  in  mind  the  fact  that  a  message 
transmission  time  is  not  always  equal  to  the  message  generation  time,  due  to  the  backoff  al¬ 
gorithm,  and  possible  unsuccessful  transmissions. 
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Figure  4.1.  Station's  clock,  diacjram. 
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detail,  except  for  the  backoff  algorithm,  which  is  not  known.  Because  of  that, 
the  program  must  be  able  to  be  easily  changed,  so  that  several  backoff  algo¬ 
rithms  can  be  tested.  One  last  thing  to  be  noted  is  that  the  blocking  and  dis¬ 
carding  effect,  due  to  finite  buffering,  must  also  be  included,  so  as  to  make  the 
station  as  realistic  as  possible. 

4.2.  Selecting  Environment  and  Language. 

The  major  consideration  on  the  design  of  a  simulation  program  is  where 
the  program  will  run  and  what  will  be  the  programming  language  [2].  In  our 
case,  all  possible  alternatives  were  considered.  Six  major  candidate  languages 
were  available: 

Simula 

Pascal 

PL1 

FORTRAN 

Concurrent  Euclid 

C 

In  addition,  two  machine  environments  were  available: 

The  UTCS  IBM/ 3033  and 

the  CSRG  VAX  11/780. 

Our  first,  and  most  obvious,  candidate  language  was  Simula,  a  language 
specially  designed  for  simulation  programs.  Although  some  great  advantages 
were  offered  by  Simula,  a  major  disadvantage  existed.  That  was  the  extremely 
high  cost  for  running  programs.  The  reason  was  that  the  language  was  sup¬ 
ported  only  by  the  UTCS  IBM/3033  machine,  which  has  a  very  high  cost  for  run¬ 
ning  programs  and  even  higher  for  using  the  interactive  editing  facilities.  (The 
idea  of  using  punched  cards  was  rejected  from  the  first  moment!)  A  first  esti¬ 
mate  showed  us  that  a  minimum  of  100  login  hours  and  100  run  hours  would  be 
required  for  the  project,  which  give  a  total  cost  of  100  login  hours  x  3.75 
dollars /connect  hour  +  100  CPU  hours  x  19.50  dollars/CPU  minute  a  120,000 
Dollars  (!)  [27].  Therefore  Simula  was  rejected  because  of  its  extremely  high 
cost.  For  the  same  reason,  and  since  there  were  no  additional  advantages  to  be 
offered,  the  rest  of  the  languages  running  on  the  UTCS  IBM/3033  machine  were 
also  rejected  (Pascal,  PL1,  FORTRAN). 

From  the  remaining  languages,  running  on  the  CSRG  VAX  11/780,  FORTRAN 
was  rejected  because  of  its  obvious  inferiority  against  C  and  Concurrent  Euclid 
(i.e.,  ease  of  programming,  freedom  from  errors,  better  structure,  the  UNDCf 


tUNDC  is  a  Trademark  of  Bell  Laboratories. 
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FORTRAN  optimizer  is  known  to  create  errors  in  code,  etc).  The  task  of  select¬ 
ing  one  from  the  two  remaining  languages  was  the  most  difficult  one.  Con¬ 
current  Euclid  is  a  very  modular  and  well  structure  language  [7]  but  it  does  not 
(for  the  time  being)  support  floating  point  arithmetic.  On  the  other  hand,  C 
may  not  be  as  modular  or  well  structured  as  Concurrent  Euclid  [15],  but  it  does 
support  floating  point  arithmetic  and  has  a  large  mathematical  library.  Consid¬ 
ering  the  fact  that  we  were  planning  to  test  several  backoff  algorithms  for  the 
protocol  (which  requires  easy  to  modify  programs),  we  finally  decided  to  use 
Concurrent  Euclid  for  the  main  parts  of  the  programs  and  C  for  the  parts  where 
floating  point  arithmetic  and  library  functions  would  be  needed  (*).  The  linkage 
between  the  two  language  programs  was  done  easily  according  to  some  hints, 
which  will  be  discused  in  the  next  chapter. 

4.3.  Designing  the  Simulation. 

After  the  language  selection,  our  next  step  was  to  decide  on  the  basic 
characteristics  of  the  simulation.  That  is,  whether  we  would  have  time  driven 
or  event  driven  simulation,  whether  the  simulation  features  offered  by  the 
language  could  be  of  any  use,  how  the  programs  meet  the  specifications  in  an 
optimal  way,  etc. 

It  is  true  that  a  time  driven  simulation  is  easier  to  implement  than  an 
event  driven  one.  On  the  other  hand,  event  driven  simulations  are  in  general 
much  faster  than  time  driven  ones.  For  deciding  which  would  be  best  to  imple¬ 
ment,  we  had  to  make  some  rough  calculations  on  the  time  that  would  be 
required  for  a  time  driven  simulation.  Collecting  data  from  existing  networks 
so  as  to  estimate  the  simulation  time  unit,  we  found  that  for  having  reliable 
results  we  should  use  a  time  unit  of  approximately  lOnS  [33].  But  the  CPU 
cycle  in  our  computer  is  of  the  same  order  of  magnitude,  which  means  that  we 
would  have  to  spent  at  least  1  CPU  second  for  every  simulated  second  (and 
maybe  more).  Obviously  this  would  result  to  a  very  slow  and  costly  simulation. 
For  that  reason  we  decided  to  implement  an  event  driven  simulation,  which  is 
expected  to  be  much  faster. 

Trying  to  meet  the  specifications  described  above  within  an  event  driven 
simulation,  we  found  that  the  best  method  was  to  simulate  the  actual  behavior 
of  each  station,  and  by  incorporating  a  number  of  "stations"  to  simulate  the 

(*)  We  also  considered  the  idea  to  use  Assembly  programs  for  the  floating  point  arithmetic, 
resulting  in  faster  code,  but  the  idea  was  soon  abandoned  since  we  would  have  to  modify  the 
Assembler.  That  was  because  the  Assembler  mounted  on  VAX  UNIX  is  the  PDPll/50  Assem¬ 
bler  and  not  the  VAX  Assembler,  and  it  does  not  support  the  full  VAX  hardware  floating  point 
arithmetic  [8]. 
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entire  network.  The  concurrency  offered  by  the  language  would  make  that  easy 
to  implement,  and  since  the  stations  operate  independently  (and  simultane¬ 
ously),  we  would  achieve  a  more  realistic  simulation.  In  addition,  the  modular 
type  of  the  language  would  support  an  implementation  similar  to  the  one  of  a 
real  station,  where  each  module  would  simulate  a  hardware  or  software  part  of 
the  real  station. 

One  feature  offered  by  the  language  for  simulation  purposes  is  the  busy 
command.  Whenever  a  process  executes  a  busy  command,  it  goes  to  sleep  for  a 
specific  length  of  simulated  time  (for  more  information  see  [7]).  Unfortunately 
we  could  not  use  that  feature  because  of  the  special  type  of  our  simulation. 
Our  problem  was  that  we  would  have  been  unable  to  wake  up  a  process  during 
its  busy  time.  In  our  model,  each  process  (station)  knows  the  time  that  it  would 
perform  its  next  action  if  it  was  undisturbed  by  the  outside  world.  However,  it 
may  change  that  time  (and  also  the  action  to  be  performed)  in  response  to  sig¬ 
nals  from  the  outside  world  (eg.  a  change  of  the  state  of  the  channel).  Thus,  we 
must  be  able  to  wake  the  process  at  any  time. 

Our  last  design  consideration  was  what  data  should  we  collect  from  the 
simulation.  Since  we  did  not  know  exactly  what  we  may  be  interested  in,  we 
decided  to  collect  all  data  related  to  the  channel  traffic.  That  is,  not  only  the 
generation  and  transmission  times  of  a  message,  but  also  the  whole  history  of 
the  message,  which  includes  the  times  of  all  the  possible  unsuccessful 
transmissions.  This  way  we  would  be  able  to  calculate  any  measures  without 
rerunning  the  simulation. 
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5.  Implementing  the  Simulation  Programs. 

After  setting  the  program  specifications,  our  next  step  was  to  proceed  to  a 
top-down  design  of  the  simulation.  The  design  analysis  is  divided  into  five  levels 
(plus  the  specifications  level  presented  in  the  previous  chapter).  In  the  first 
level  we  separate  the  independent  parts  of  the  program  giving  a  general 
description  of  their  use.  In  the  second  level  the  operations  of  the  program 
parts,  defined  in  the  first  level,  are  described  in  detail.  The  thirc£ level  is  con¬ 
cerned  with  implementation  details  and  methods  to  solve  the  implementation 
problems.  The  fourth  level  is  the  pseudo  code  level,  while  the  fifth  is  the  trans¬ 
lation  of  the  pseudo  code  to  Concurrent  Euclid  code. 

In  this  chapter  we  will  present  the  first  three  levels  of  the  analysis  and  dis¬ 
cuss  some  of  the  major  problems  found  during  the  program  testing. 

5.1.  Design  Analysis.  Level  1. 

Since  the  simulation  will  run  under  concurrent  control,  the  programs  can 
be  firstly  separated  into  two  major  categories.  The  programs  that  simulate  the 
independent  station  processes,  and  the  control  programs  (i.e.,  the  programs 
needed  for  the  synchronization  of  the  station  processes).  In  the  following,  the 
above  two  major  categories  are  independently  analyzed. 


5.1.1.  The  Station. 

Since  we  simulate  a  CSMA  (Carrier  Sense  Multiple  Access)  protocol,  the  sta¬ 
tion  will  continuously  sense  the  status  of  the  channel,  to  find  whether  it  is 
busy,  idle  or  collide  (if  we  have  collision  detection).  Obviously  the  station  will 
be  in  steady  state  when  there  is  no  change  in  the  channel  sensing,  and  adapt  its 
function  whenever  a  change  in  the  channel  is  detected.  The  channel  sensing  of 
a  station,  can  be  of  three  types: 

a)  idle, 

b)  busy, 

c)  collide  {*). 

Regarding  the  fact  that  a  station  can  either  be  transmitting  a  message  or 

(')  Whenwedonot  have  collision  detection,  the  station  can  only  have  an  a  posteriori  sense 
of  the  channel  status,  due  to  negative  or  non  existing  acknowledgement,  at  the  end  of  its 
transmission.  As  a  result,  the  only  difference  between  having  and  not  having  collision  detec¬ 
tion  is  at  the  time  at  which  the  knowledge  of  the  collide  channel  will  be  used  or  become 
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not,  the  state  of  the  station  can  be  described,  in  combination  with  its  channel 
sensing,  to  be  one  of  the  following  five: 

0)  channel  sensing  :  idle 

station  status  :  idle  waiting 

The  station  senses  idle  channel  and  it  does  not  have  anything  to 
transmit  for  the  time  being. 

1)  channel  sensing  :  busy 

station  status  :  transmitting  a  message 

The  station  transmits  a  message  and,  obviously,  the  channel  is  sensed 
busy.  Also  there  are  no  other  messages  in  the  channel  passing  in 
front  of  the  station. 

2)  channel  sensing  :  collide 

station  status  :  transmitting  a  message 

There  is  a  collision  taking  place,  in  which  the  station  is  involved.  (If 
we  have  collision  detection  the  station  will  stop  transmitting  after  the 
collision  recovery  time.) 

3)  channel  sensing  :  busy 
station  status  :  idle  waiting 

A  successful  message  transmission  from  another  station  is  sensed.  We 
can  say  that  the  station  is  "receiving”  a  message  (*). 

4)  channel  sensing  :  collide 
station  status  :  idle  waiting 

There  is  a  collision  taking  place  in  which  the  station  is  not  involved. 

As  we  said,  the  station  will,  in  general,  change  its  state  whenever  it  senses 
a  change  in  the  channel.  The  channel  sensing  can  change  because  the  start  or 
the  end  of  a  message,  is  passing  by.  On  the  other  hand,  the  owner  of  the  mes¬ 
sage  that  changed  the  channel  status,  can  either  be  the  station  itself  or  some 
other  station.  So  the  reason  of  the  channel  sensing  change,  can  be  described 
by  a  two  element  vector  (  why  ,  who  ),  where 


available,  to  the  station.  In  our  presentation  we  assume  that  the  station  has  always  a  com¬ 
plete  and  exact  knowledge  of  the  channel  status  and  thus  we  can,  by  altering  the  time  at 
which  it  will  use  that  knowledge,  represent  both  cases  of  having  and  not  having  collision 
detection.  More  about  collision  sensing  can  be  found  in  [25]. 

(  )  The  true  destination  of  the  message  is  unimportant  for  our  purposes,  since  every  station 
will  receive  a  message  correctly  whenever  any  single  station  does,  provided  we  enforce  a 
minimum  message  length  -  see  [11]. 
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why.  defines  the  cause  of  the  channel  sensing  change,  and  it  is  0  for  the  start  of 
a  message  and  1  for  the  end  of  a  message. 

who.  denotes  the  owner  of  the  mentioned  message,  and  it  is  0  if  it  is  the  station 
itself  and  1  if  any  other  station. 

Figure  5.1  gives  the  state  transition  diagram  of  the  station,  and  the  reason 

causing  it.  Due  to  the  unslotted  nature  of  the  network,  transitions  like  0  ->  2, 

0  -»  4,  4  -»  1  etc.  are  unlikely  to  occur  and  we  can  ignore  them  (  ).  '*Also  note 

(M)  (M) 

that  transitions  2  -+  2  and  4  -»  4  are  not  normally  detectable  by  the  station. 
It  must  be  clear  by  now  that  when  the  station  is  in  states  2  or  4,  it  will  remain 
there  or  change  to  state  0,  depending  whether  after  the  change  in  channel 
sensing,  the  channel  continues  to  be  collide  or  became  idle,  respectively. 

The  time  that  the  station  can  spend  in  each  of  its  possible  five  states  is 
outside  our  concerns,  since  it  depends  on  the  specific  protocol  followed.  How¬ 
ever  we  can  say  that  the  station  can  spend  an  infinite  amount  of  time  only  at 
state  0,  and  stay  at  any  other  state  only  for  limited  time. 

Define  an  event  to  be  anything  that  will  change  the  channel  sensing.  We 
can  easily  see  that  all  the  state  transitions  in  the  station  are  due  to  an  event 
and  that  the  station  will  continue  acting  in  the  same  way,  (ie.,  remain  at  its 
present  state)  until  a  new  event  occurs. 


5.1.2.  The  Control 

The  basic  idea  in  using  concurrency,  is  that  a  station  process  will  operate 
independently  from  all  other  station  processes,  according  to  information 
passed  to  it  from  the  channel  and  its  own  status.  That  means  that  special  con¬ 
siderations  in  simulating  the  channel,  had  to  be  taken.  The  channel’s  operation 
would  be  to  receive  a  start  (or  end)  of  a  message  from  a  station  and  propagate 
it  to  the  other  stations,  according  to  the  network  topology. 

Since  the  simulation  was  meant  to  be  event  driven,  propagating  a  message 
through  the  channel,  means  to  set  events  for  the  stations.  On  the  other  hand, 
in  an  event  driven  simulation  actions  are  assumed  to  be  performed  in  negligi¬ 
ble  time,  and  after  the  action  is  taken,  the  station  (process)  is  on  idle  waiting 
state  until  the  next  event.  Since  we  do  not  want  to  spent  CPU  time  for  idle  wait¬ 
ing,  we  can  set  the  process  to  sleep  and  wake  it  up  at  the  next  event.  In 


( #)  These  state  transitions  mean  that  two  events  occur  at  exar.tJy  the  same  moment.  In  an 
unslotted  network,  where  time  runs  continuously,  the  probability  of  such  a  coincidence  is 
negligible. 


state 
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Figure  5.1.  Station's  state  transition  diagram. 
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accordance  to  the  above  schema,  and  since  the  station  knows  nothing  about  the 
actions  of  the  other  stations,  it  will  have  to  go  to  sleep  based  only  on  its  own 
perception  of  the  future,  and  yet  be  ready  to  be  awakened,  due  to  an  event  from 
an  other  station,  at  any  time.  That  means  that  the  busy  statement  can  not  be 
used  for  setting  a  station  to  sleep,  and  thus  some  other  method  must  be  imple¬ 
mented.  What  we  finally  decided  to  use,  is  based  on  the  same  idea  with  the  way 
that  the  busy  statement  works.  A  control  process  will  keep  track  of  the  sleeping 
stations  and  the  events  to  happen.  By  jumping  through  the  events,  it  will  wake 
the  corresponding  stations,  providing  them  also  with  the  information  needed. 
Obviously  the  control  process  must  be  able  to  wake  more  than  one  station,  if 
needed,  at  a  single  event  time. 

5.2.  Design  Analysis.  Level  2. 

In  the  second  level  of  the  design  analysis,  we  are  mainly  concerned  with 
describing  the  operations  of  the  program  parts  defined  in  the  first  level,  without 
being  concerned  with  implementation  details.  This  level  is  basically  meant  to 
analyze  the  station’s  operations  in  each  of  its  states.  Therefore,  there  is  noth¬ 
ing  to  be  said  for  the  control  process  here. 

As  mentioned,  the  station  will  be  awakened  by  the  control  process  when¬ 
ever  an  event  occurs,  and  will  be  supplied  with  information  regarding  the  rea¬ 
soning  of  been  awakened.  That  will  be,  under  which  station's  request  it  is  been 
awakened  (its  own  or  somebody  else’s),  and  for  what  reason  (to  either  start  or 
end  a  message  transmission).  Depending  on  its  current  state,  the  station  will 
(in  general)  change  its  state  and  perform  the  operations  needed  for  the  state 
transition.  In  the  following  the  operations  for  every  state  transition  are 
described. 

(0.0) 

0  ->  1 

A  message  transmission  by  the  station  is  to  start.  The  station  will  place 
the  start  of  the  message  into  the  channel,  stop  its  virtual  clocks  and  go  to 
sleep  until  the  end  of  the  transmission. 


(ai) 

0  ->  3 

A  message  is  sensed  in  the  idle  channel.  The  station  is  now  receiving.  It 
will  stop  its  virtual  clocks,  cancel  its  scheduled  message  transmission  and 
go  to  sleep  for  an  undefined  time  period. 


(to) 

1  -*  0 

The  transmission  of  the  message  has  been  successfully  completed.  The 
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station  will  place  the  end  of  the  message  into  the  channel,  enable  its  vir¬ 
tual  clocks,  calculate  its  next  message  transmission  time  and  go  to  sleep 
until  then. 

(0.1) 

1  ->  2 

A  second  message  is  sensed  in  the  channel  while  the  station  is  transmit¬ 
ting.  A  collision  in  which  the  station  is  involved  is  taking  plac^.  If  collision 
detection  is  available,  the  station  will  set  itself  to  end  the  transmission 
after  the  recovery  time.  Otherwise  the  message  transmission  will  end 
after  the  complete  message  has  been  transmitted.  At  this  point  the  mes¬ 
sage  rescheduling,  in  accordance  with  the  collision  resolution  algorithm, 
will  be  performed. 

(i.  *) 

2  ->  0 

The  ending  tail  of  a  message  passing  in  front  of  the  station  ended  a  colli¬ 
sion  in  which  the  station  was  involved.  The  channel  is  now  idle  again.  The 
station  will  enable  its  virtual  clocks,  calculate  its  next  message  transmis¬ 
sion  time  and  go  to  sleep  until  then. 

(i.o) 

2  ->  2 

The  station  stopped  its  colliding  transmission  but  the  channel  is  still  busy 
(collide).  Except  for  placing  the  end  tail  of  its  transmission  into  the  chan¬ 
nel,  no  further  actions  will  be  taken  from  the  station  (in  respect  of  course 
with  the  collision  resolution  algorithm.) 

(M) 

2  ->  2  (Non  detectable). 

This  state  transition  is  not  (normally)  detectable  by  the  station.  Neverthe¬ 
less,  we  still  need  it  in  order  to  keep  track  to  the  channel  status.  Its  exact 
use  will  be  explained  in  the  next  section.  Obviously  the  station  will  take  no 
action  in  this  state  transition. 


(u) 

3  -*  0 

The  message  reception  has  been  completed  successfully.  The  station  will 
enable  its  virtual  clocks,  calculate  its  next  transmission  time  and  go  to 
sleep  until  then. 


(o.i) 

3  -*  4 

A  collision  is  sensed  to  be  talcing  place  between  other  stations.  The  station 
will  react  with  respect  to  the  collision  resolution  algorithm. 
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at) 

4  -»  0 

The  collision  in  which  the  station  was  not  involved  ended.  The  station  will 
enable  its  virtual  clocks,  calculate  its  next  transmission  time  and  go  to 
sleep  until  then.  These  actions  will  be  done  with  respect  to  the  collision 
resolution  algorithm. 

(M) 

4  ->  4  (Non  detectable). 

This  state  transition  is  not  (normally)  detectable  by  the  station.  Neverthe¬ 
less,  we  still  need  it  in  order  to  keep  track  of  the  channel  status.  Its  exact 
use  will  be  explained  in  the  next  section.  Obviously  the  station  will  take  no 
action  in  this  state  transition. 

5.3.  Design  Analysis.  Level  3. 

In  this  analysis  level  the  implementation  problems  are  considered.  Due  to 
the  concurrency  used,  some  problems  came  to  light  only  after  we  had  com¬ 
pleted  the  implementation,  when  the  verification  tests  were  run.  These  were 
the  most  difficult  to  trace,  since  any  attempt  to  change  the  code  (in  order  to 
insert  tracing  points)  was  leading  to  a  different  execution  flow.  These  problems 
will  be  discussed  in  the  next  section. 

Our  first  implementation  problem  was  the  time  representation.  That  was 
because  we  were  implementing  a  continuous  time  simulation,  and  in  a  com¬ 
puter  we  can  only  have  discrete  counting.  From  a  small  data  collection 
[17,19,33,32]  we  came  to  the  conclusion  that  a  time  unit  of  InS  (10_95ec) 
would  give  us  an  excellent  continuous  time  approximation.  A  problem  resulting 
from  this  was  how  to  represent,  with  accuracy  of  1  nS,  time  values  of  the  order 
of  hour.  That  was  because  the  maximum  representable  integer  in  Concurrent 
Euclid,  is  a  longlnteger  and  its  maximum  value  is  23l-l  =  2,147,483,647.  That 
means  that  with  normal  counting  we  would  be  able  to  represent  time  values  up 
to  only  a  couple  of  seconds(!).  Obviously  this  was  not  our  case,  since,  in  order 
to  obtain  valid  results,  we  would  like  to  run  our  programs  from  50  up  to  100 
hours  of  simulated  time.  The  problem  was  easily  solved  by  representing  time 
values  with  two  integers,  mounted  in  a  record.  The  "lower"  represents  nano¬ 
seconds  while  the  "higher"  represents  seconds.  This  way  we  were  able  to 
represent  time  values  up  to  596,000  hours  (or  68  years  !). 

In  the  rest  of  this  section  we  will  discuss  the  implementation  problems  of 
the  basic  simulation  program  and  not  the  variations  concerning  the  different 
backoff  algorithms,  which  will  discussed  in  a  later  chapter. 
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5.3.1.  The  Station. 

The  first  problem  ,n  the  station's  implementation  was  how  to  represent  the 
message  generation  processes.  A  very  good  idea  was  found  in[l2].  Their  idea 
was  to  maintain  for  every  station  a  two  dimensional  array,  M(l..K)(l..B)  ("mes¬ 
sage  table"  from  here  on),  holding  the  messages  to  be  transmitted  for  each  of 
the  K  classes,  in  a  buffer  of  size  B.  The  table  holds  packets  (messages)  queued 
at  the  station,  along  with  information  regarding  its  original  generation  time,  its 
transmission  time,  and  the  message  history  (i.e.,  the  times  of  any  previous 
unsuccessful  transmissions).  The  table  is  kept  always  full.  That  is,  at  initializa¬ 
tion  packets  are  generated  according  to  geometric  distributed  interval  times, 
with  parameters  as  specified  for  each  class,  for  all  buffer  positions.  Further¬ 
more.  during  execution  of  the  simulation,  whenever  a  packet  is  removed  from 
the  system,  (either  because  it  was  successfully  transmitted  or  because  it 
exceeded  its  maximum  limit  of  retransmissions  and  thus  must  be  discarded),  a 
new  packet  is  generated  immediately  using  the  same  geometric  distribution  of 
interarrival  times. 

The  advantages  of  this  approach  are  many.  First  of  all,  it  allows  us  to  simu¬ 
late  the  blocking  effect,  taking  place  in  a  real  station,  in  a  very  simple  way.  The 
only  thing  we  must  do,  is,  when  generating  a  new  message,  to  check  whether  its 
generation  time  is  greater  or  less  them,  the  "real  time".  That  is  because  a  mes¬ 
sage  will  be  generated  only  after  another  message  has  left  the  system,  freeing  a 
buffer  space.  That  means  that  any  message  arriving  (been  generated)  before 
the  time  that  a  message  left  the  system  (and  thus  a  buffer  space  was  available) 
will  not  find  any  buffer  free,  and  will  be  blocked  A  second  point  is  that  it  allows 
an  easy  calculation  of  the  station’s  future  program  and  easy  rescheduling  of 
the  message  transmiss;ons. 

The  next  implementation  problem  faced,  was  how  to  identify  the  channel 
status  (i.e.,  if  it  is  idle  or  busy).  As  we  mentioned  above,  the  station  would  be 
awakened  every  time  an  event  occurred.  An  event  will  simply  inform  the  sta¬ 
tion  about  the  start  or  the  end  of  a  message  passing  in  front  of  it.  Thus,  by 
keeping  track  of  the  number  of  messages  on  the  channel  in  front  of  the  station, 
we  can  conclude  the  channel  status.  That  can  be  easily  done  by  simply  increas¬ 
ing  a  variable  by  one,  for  every  start  of  a  message,  and  decreasing  it  by  one,  for 
every  end  of  a  message.  When  the  variable  is  zero,  the  channel  is  idle.  Obvi¬ 
ously  the  station  will  only  use  the  information  that  the  channel  is  busy  or  idle, 
and  not  how  many  messages  are  in  the  channel. 

Since  the  station  can  determine  the  channel  status,  it  must  use  it  in  order 
to  run  its  virtual  clocks.  The  problem  here  is  that,  since  the  simulation  is 
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event  driven,  the  virtual  clocks  cannot  run  continuously,  as  they  would  in  a 
real  station.  From  the  fact  that  between  two  events  nothing  will  happen  to 
change  the  state  of  the  channel,  the  station  can  calculate  its  virtual  clocks 
readings  at  the  end  of  the  inter-event  time.  Note  that  the  calculation  must 
only  be  done  when  in  the  inter-event  time,  the  station  was  sensing  idle  channel. 
To  achieve  the  above,  the  time  of  the  event  at  which  the  channel  sensing 
changed  from  busy  to  idle  will  be  recorded,  and  at  the  next  event  (which  always 
will  change  the  channel  to  busy)  the  inter-event  time  will  be  fo\ind  and  the 
advance  of  the  virtual  clocks  will  be  calculated.  Also  note  that  the  calculation 
of  the  virtual  clocks’  readings,  is  a  complicated  one,  because  of  the  fact  that 
the  clock  must  slow  down  when  it  catches  up  with  real  time. 

The  above  method  of  running  the  virtual  clocks  creates  the  problem  of  how 
the  station  will  determine  when  a  message  transmission  will  take  place.  That  is 
because  a  message  will  be  transmitted  when  the  virtual  clock's  reading 
becomes  equal  to  its  generation  time.  Advancing  the  virtual  clocks  by  random 
steps,  obviously,  does  not  support  the  message  transmission  process.  What  we 
did,  was  to  set  an  event  at  exactly  the  time  that  the  message  transmission 
would  take  place.  This  way,  the  station  would  be  awakened  at  the  correct  time 
to  transmit  its  message.  Because  a  message  transmission  is  controlled  by  the 
virtual  clocks,  while  an  event  takes  place  at  some  real  time,  we  are  forced  to  do 
complicated  calculations,  in  order  to  find  the  real  time  moment  where  the 
transmission  takes  place.  That  is,  the  moment  that  the  virtual  clock  reading 
becomes  equal  to  the  message  generation  time. 

The  calculations  for  finding  the  next  message  transmission  time,  would 
have  to  be  done  at  the  beginning  of  an  idle  period.  (Obviously,  because  the 
station's  virtual  clocks  run  only  during  idle  periods,  and  thus  a  transmission 
can  occur  then.)  In  the  meanwhile  a  message  from  an  other  station  may  appear 
in  the  channel,  changing  its  status  to  busy  and  thus  stopping  the  station  virtual 
clocks.  At  the  end  of  the  transmission  period,  the  channel  will  again  become 
idle.  Our  concern  at  this  point  was  whether  the  information  about  the  next 
message  transmission  time,  calculated  previously,  can  be  of  any  use.  That  is 
because  the  calculations  are  so  complicated  (and  CPU  time  consuming),  that 
we  would  like  to  perform  them  as  rarely  as  possible.  What  we  finally  found  was 
that  the  information  can  be  used,  but  it  will  take  even  more  complicated  calcu¬ 
lations  to  result  to  something  really  useful.  For  example,  with  more  than  one 
priority  class,  a  reversal  in  the  order  of  scheduled  transmissions  may  appear 
(•).  Due  to  this,  we  decided  to  recalculate  the  next  message  transmission  time 

(•)  Consider,  for  example,  that  we  have  only  two  classes,  and  that  at  some  point  both 
classes'  virtual  clocks  run  with  real  time.  If  the  second  class  has  a  message  transmission  at 
time  a  while  the  first  at  time  a  +e,  obviously,  if  the  station  left  undisturbed,  the  second 
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every  time  the  channel  became  idle.  An  improvement  here  was  to  use  the 
information  about  the  next  message  transmission  time,  in  setting  the  virtual 
clocks,  when  the  actual  transmission  finally  was  taking  place. 

In  order  to  be  able  to  reschedule  the  messages  after  a  collision  with 
minimal  effort,  we  used  the  meaning  of  transmission  time  of  a  message.  That  is 
the  time  that  the  message  will  be  transmitted,  or  in  other  words,  the  time  with 
which  the  virtual  clock  reading  must  become  equal,  in  order  for  the  message  to 
be  transmitted.  At  generation  time  the  transmission  time  of  a  message  is  equal 
to  its  generation  time.  If  the  message  collides,  the  only  thing  that  has  to  be 
changed  by  the  retransmission  strategy  ,  is  the  message’s  transmission  time. 
This  way,  there  will  be  no  distinction  between  a  collide  and  a  new  message,  as 
far  as  the  rest  of  the  parts  of  the  program  are  concerned.  It  also  allows  the  col¬ 
lision  resolution  programs  to  be  easily  changed. 


5.3.2.  The  Control, 

As  we  mentioned  above,  the  main  purpose  of  the  control  process  was  to 
implement  the  busy  statement  in  a  more  useful  way.  A  result  of  this  was  that 
the  control  process  would  also  control  the  "real  time"  clock.  The  idea  for  the 
implementation  is  similar  to  the  one  with  which  the  busy  statement  is  imple¬ 
mented  [14].  A  linked  list  of  events  is  maintained  by  the  process,  with  the 
events  ordered  in  increasing  time  order.  Simultaneous  events  are  branched  to 
the  list  (Figure  5.2.).  Each  element  in  the  list  has  four  pointers.  Two  of  them 
are  pointing  to  the  previous  and  next  event  in  time,  while  the  other  two  to  the 
above  and  lower  simultaneous  events.  The  process  also  maintains  an  array  of 
conditions  one  for  each  active  process  in  the  simulation. 

Each  station  process,  when  it  want  to  go  to  sleep,  will  call  an  in  monitor 
procedure,  in  which  it  will  first  increase  a  variable,  giving  the  number  of  sleep¬ 
ing  stations,  by  one,  and  then  wait  on  its  condition  from  the  condition  array. 
Note  that  each  station  process  has  a  unique  number  identifying  it.  The  last  sta¬ 
tion  going  to  sleep  (the  one  that  will  find  the  number  of  sleeping  stations  equal 
with  the  number  of  stations  in  the  network),  before  executing  the  wait  it  will 
signal  the  control  process,  waiting  on  a  special  condition,  to  resume  execution. 
The  control  process  will  take  the  first  event  from  the  event  list,  set  the  "real 
time"  to  the  event  time,  place  the  event  information  on  a  special  variable  and 
finally  signal  the  corresponding  station  process.  By  signaling  the  station 

class  will  transmit  first.  Assume  now  that  a  message  from  an  other  station  appears  in  the 
channel  at  time  a  -e,  changing  the  channel  status  to  busy.  At  the  end  of  the  busy  period, 
the  first  class'  virtual  clock  will  start  running,  while  the  second's  will  remain  stopped.  Thus 
the  first  class  will  now  transmit  first. 
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Figure  5.2.  Event  list  layout. 
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process,  the  control  process  will  go  out  of  the  monitor  and  become  blocked 
[14].  The  signaled  process  will  enter  the  monitor,  receive  the  information  and 
exit  from  it,  resuming  independent  execution.  After  that,  the  control  process 
will  reenter  the  monitor,  check  whether  there  is  a  simultaneous  event,  in  which 
case  the  cycle  will  be  repeated,  and  go  to  sleep  by  executing  a  wait  in  a  special 
condition-  A  problem  in  the  above  method  was  what  will  happen  if  the  control 
tries  to  signal  the  last  to  sleep  station  process,  which  was  the  one  that  signaled 
it.  That  is  because  the  process  under  discussion,  is  not  waiting  oh  any  condi¬ 
tion  but  is  simply  blocked  outside  the  monitor  (since  it  signaled  the  control 
process),  and  thus  it  can  not  "catch"  the  signal  from  the  control.  The  solution 
given,  was  to  have  the  station  process  check  if  there  is  information  to  be  passed 
in  the  information  exchange  variable.  This  way  the  process,  before  executing  a 
wait,  would  check  whether  there  is  information  from  the  control,  and  if  it  did 
receive  it,  clear  the  exchange  variable  and  resume  execution  immediately 
without  waiting. 

The  event  list  is  organized  inside  a  monitor,  because  all  stations'  processes 
can  insert  and  delete  events  at  the  any  time,  as  it  will  be  explained  in  a  next 
section.  In  order  to  minimize  the  amount  of  work  needed  .to  be  done,  when 
deleting  or  inserting  an  event,  special  methods  are  used.  Firstly,  when  a  single 
event  has  to  be  inserted  or  deleted,  the  simplest,  and  most  obvious  method  is 
used.  That  is,  alter  finding  where  the  event  will  be  placed,  in  the  case  of  inser¬ 
tion,  the  list  is  broken  at  the  specific  point  and  relinked  by  resetting  the 
pointers.  When  deleting,  the  event  is  removed  and  the  pointers  of  the  previous 
and  next  events  are  updated  (if  a  previous  and  a  next  event  exist).  In  the  case 
of  multiple  events,  the  new  event  will  be  inserted  last  in  the  multiple  event 
branch.  On  deletion,  the  last  event  in  the  branch  will  replace  the  deleted  event 
in  the  list.  This  way,  the  only  pointer  to  be  updated  will  be  the  one  which  was 
previously  pointing  to  the  last  event.  This  pointer,  will  be  simply  set  to  null 
(which  means  that  the  corresponding  event  is  now  the  last  in  the  branch).  We 
must  finally  note  that  in  order  to  minimize  the  search  in  the  list,  an  extra 
pointer  is  kept,  pointing  to  the  last  referenced  event.  This  way,  because  most 
of  the  search  will  be  done  for  insertions,  we  have  the  most  probable  point  to 
start  the  searching. 


5.3.3.  The  Channel. 

A  special  part  of  the  simulation  programs,  was  the  implementation  of  the 
channel.  Because  the  notion  of  the  channel  does  not  explicitly  appear  in  the 
programs,  we  feel  that  an  analysis  of  the  operations  simulating  the  channel  is 
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needed  at  this  analysis  level. 

The  channel  is  closely  related  to  the  network  topology.  Since  we  are  imple¬ 
menting  an  unrestricted  network  topology  simulation,  the  best  method  to 
encode  the  information  about  the  network  topology,  is  through  the  propagation 
delays.  As  we  previously  mentioned,  each  station  maintains  a  list  of  its  propa¬ 
gation  distance  from  all  other  stations,  sorted  in  increasing  order.  When  the 
station  is  ready  to  transmit  a  message,  the  only  thing  it  has  to^do  is  to  set 
events  for  the  other  stations,  so  that  they  will  be  informed  about  the  start  of  a 
message.  That  can  be  easily  accomplished,  since  the  station  knows  how  much 
time  will  it  take  for  its  message  to  reach  all  other  stations.  By  adding  the  pro¬ 
pagation  delay  for  every  other  station  to  "real  time",  the  event  time  at  which 
its  message  will  reach  the  station  can  be  found,  and  the  event  can  be  then 
easily  set.  At  the  end,  the  station  will  set  an  event,  referring  to  itself,  signifying 
the  end  of  its  message  transmission.  Obviously  this  last  event  will  be  set  after  a 
time  interval  equal  to  the  message  length.  If  the  message  is  finally  success¬ 
fully  transmitted,  the  station  will  wake  at  the  event  time  set  by  it,  end  end  its 
transmission,  by  setting  another  series  of  events  for  the  other  station  (which 
are  equivalent  to  the  propagating  end  of  its  message).  Since  now  the  channel 
will  be  idle  in  front  of  the  station,  it  will  calculate  its  next  message  transmis¬ 
sion,  set  the  event  in  the  list  and  go  to  sleep.  If  in  the  meanwhile,  some  other 
station  starts  a  transmission,  and  the  event  set  for  our  original  station  by  the 
other  stations  is  prior  to  the  event  set  by  the  station  itself,  the  station,  when 
awakened,  it  will  remove  the  event  signaling  the  start  of  its  own  message 
transmission.  At  that  moment,  the  station  will  have  no  waking  event  in  the  list. 
The  event  will  be  set  by  the  transmitting  station  at  the  end  of  its  transmission, 
or  by  some  other  station  which  starts  transmitting  in  the  meanwhile.  It  easy  to 
see  that  this  last  case  will  be  a  collision. 

Define  a  token  to  be  a  message,  or  a  fragment  of  a  message,  shorter  than 
the  end  to  end  propagation  time.  This  way,  a  token  will  have  both  its  start  and 
end  on  the  channel,  at  the  same  moment.  (This  is  very  common  in  sattelite 
networks  [28].)  What  we  must  note  is  that  the  simulation  can  easily  handle  pro¬ 
pagating  tokens  through  the  channel,  but  for  this  case  a  special  method  is 
needed,  in  order  to  decide  whether  a  message  was  finally  collide  or  not.  That  is, 
the  simulation  maust  be  extended  to  include  explicit  destinations  for  each  mes¬ 
sage,  and  the  throughput  would  be  found  from  the  messages  received  correctly. 
On  the  other  hand  if  the  transmission  length  is  always  greater  than  2a,  then  all 
stations  will  uniquely  identify  the  status  of  a  message,  and  no  special  con¬ 
siderations  are  needed  [  1 1  ]. 
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5.3.4.  The  Libraries. 

An  indispensable  part  of  our  simulation  programs  are  the  libraries.  Two 
libraries  have  been  implemented  for  use  with  the  simulating  programs.  An 
arithmetic  operations  library  and  a  random  number  generating  library. 

As  mentioned  in  previous  section,  we  represented  time  values  as  a  record 
consisting  of  two  long  integers,  named  TIME.  Obviously  some  arithmetic  opera¬ 
tions  would  have  to  be  performed  among  TIME  records.  Since  the  systdm  could 
not  support  arithmetic  operations  on  records  of  this  type,  we  had  to  implement 
a  special  arithmetic  operations  library.  Also  comparison  functions  would  have 
to  be  implemented,  so  as  to  make  the  handling  of  the  TIME  variables  easier. 
The  arithmetic  operations  we  needed  for  the  TIME  records  were  the  basic  ones. 
That  is,  addition  and  subtraction  between  TIME  variables,  plus  multiplication 
and  division  between  a  TIME  variable  and  an  integer.  Implementation  of  addi¬ 
tion  and  subtraction  in  Concurrent  Euclid  was  a  trivial  task.  On  the  other  hand, 
multiplication  and  division  were  very  hard  to  implement  in  an  efficient  way. 
Writing  code  in  Concurrent  Euclid  implementing  multiplication,  for  example, 
would  make  the  program  very  slow.  Also  it  was  not  a  good  idea  since,  in  the 
worst  case,  we  were  able  to  use  assembly  code,  which  supports  extented  preci¬ 
sion  arithmetic  and  is  very  fast  (*),  Because  the  use  of  assembly,  would  make 
the  code  unreadable  and  highly  machine  dependent,  we  finally  decided  to  use 
the  double  precision  arithmetic  supported  by  the  C  language,  by  linking  the  two 
languages  programs.  Note  that  in  this  linkage,  considerations  were  taken  so 
that  the  linkage  to  be  invisible  by  the  Concurrent  Euclid  programs,  which  would 
have  to  call  only  Concurrent  Euclid  procedures.  One  hint  for  the  two  languages 
linkage  was  that  the  long  integers  were  completely  compatible  in  both 
languages,  and  that  the  argument  list  between  the  Concurrent  Euclid  and  the  C 
procedures,  would  have  to  be  inverted  in  the  procedure  call.  (If  for  example, 
the  argument  list  appearing  in  the  Concurrent  Euclid  call  was  (al,a2,a3),  in  the 
C  procedure  it  would  appear  as  (a3,a2,al).) 

The  idea  to  link  C  programs,  had  also  the  advantage  that  it  allowed  us  to 
use  the  C  library  functions  (ie.,  logarithms,  exponential,  random  number  gen¬ 
erators,  etc).  These  functions  were  needed  in  order  to  transform  [9]  the  uni¬ 
formly  distributed  random  numbers,  returned  from  the  randQ  function  [29]  to, 
say,  geometrically  distributed  ones.  In  the  final  implementation,  all  the  ran- 

(  )  Ln  the  VAX  assembly  language,  we  have  full  support  in  arithmetic  operations  with  very 
long  integers.  By  using  the,  existing  in  the  assembly  language,  transformation  operations, 
we  can  translate  a  TIME  record  to  a  very  long  integer  and  work  it  in  assembly  code  level.  In 
fact,  this  improvement,  will  result  in  a  much  faster  simulation  code.  The  only  problem  is 
that,  for  the  time  being,  the  CSRG  VAX  does  not  have  the  corresponding  assembler. 
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dom  number  generating  library  was  written  in  C,  and  dummy  Concurrent  Euclid 
procedures  were  used  to  perform  the  data  transfer  between  the  two  languages 
programs. 

One  final  thing  that  we  must  make  note  of,  is  that  the  statistical  output  is 
performed  via  C  programs.  That  was  done  because  it  is  easier  in  the  C  language 
to  handle  floating  point  output. 

5.4.  The  Run  Time  Problems. 

After  completing  the  implementation,  verification  run  tests  were  per¬ 
formed.  The  tests  were  done  in  steps.  First  we  started  testing  the  low  level  pro¬ 
grams  (i.e.,  the  libraries),  and  when  we  were  convinced  of  their  correctness,  a 
higher  level  program,  using  the  previous  level,  was  tested.  This  way  we  were 
able  to  verify  the  program  correctness  very  efficiently  and  locate  the  errors 
easily.  Up  to  this  point,  the  errors  found  were  very  common  ones  (i.e.,  misspel¬ 
ling  of  variable  names,  omission  to  initialize  some  variables,  etc.)  and  were 
corrected  easily.  Final  tests  of  the  program  as  a  unit,  revealed  some  logical 
errors.  Tracing  these  errors  was  a  difficult  task,  because  of  the  way  the  con¬ 
currency  was  working.  The  problem  was  that  in  trying  to  trace  a  bug,  we  had  to 
add  more  calls  to  debugging  procedures,  to  print  the  information  needed.  But 
by  adding  procedure  calls,  we  were  changing  the  flow  of  execution,  because  of 
the  random  number  generators,  and  thus  we  were  usually  unable  to  reproduce 
the  bug  with  more  diagnostic  output.  The  reason  for  that  was  that  Concurrent 
Euclid  runs  under  a  kernel  simulation  and  that  the  time  slot  assignment  is  per¬ 
formed  whenever  a  begin  or  end  is  reached  [13].  This  way,  because  the  random 
numbers  are  given  with  a  specific  sequence,  each  process  was  drawing  a 
different  random  number  when  generating  a  new  message,  and  thus  changing 
the  program  flow.  The  only  way  for  tracing  such  bugs,  was  to  add  assertion 
statements,  which  do  not  change  the  program  flow,  and  try  to  find  with  succes¬ 
sive  runs,  the  flow  of  execution  and  trace  the  origin  of  the  bug.  Two  major  bugs 
of  this  type  were  found.  In  the  following  we  describe  these  bugs  among  with  the 
solutions  given. 

In  the  original  design,  the  message  table  was  consisted  of  cyclic  lists,  one 
for  each  priority  class,  and  a  vector  was  holding  the  heads  of  the  cyclic  lists. 
The  advantage  of  this  schema  was,  as  thought,  that  whenever  a  message  was 
leaving  the  system,  the  generated  message  could  be  placed  in  the  position 
occupied  by  it  and  by  a  simple  increase  to  the  head  pointer,  form  the  updated 
list.  The  mistake  in  this  approach  was  found  during  the  tests,  where  after  a 
while  the  messages  in  the  cycle  were  ordered  in  an  almost  random  way.  That 
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happened  because  when  we  rescheduled  a  message  (after  it  had  collided)  there 
was  a  chance  to  set  it  far  in  the  future.  In  the  meanwhile  new  messages  would 
arrive,  and  would  be  placed  at  the  end  of  the  list  so  that  the  list  was  no  longer 
sorted  and  the  simulation  collapsed. 

Because  of  the  above,  some  moving  around  of  the  messages  would  have  to 
done  (*).  Our  final  decision  was,  that  since  we  could  not  avoid  moving  the  mes¬ 
sages  around  in  the  message  table,  insertion  sort  [10]  can  be  used  for  every 
new  or  rescheduled  message,  and  thus  keep  the  lists  sorted.  Also  this  way  we 
would  have  the  head  of  the  lists  (next  message  to  be  transmitted)  to  be  always 
at  the  first  array  position. 

The  second,  and  most  difficult  to  trace  bug,  appeared  in  the  way  that  the 
information  exchange  was  performed  when  a  process  was  awakened.  As  we  said, 
in  order  to  awaken  a  station  process,  the  control  process  was  placing  the  infor¬ 
mation  needed  to  be  passed,  in  a  special  in  monitor  variable  (actually  a  record), 
and  signaling  the  corresponding  process.  The  problem  in  this  approach  (whose 
operation  was  described  in  the  previous  section)  was  that  there  was  nothing  to 
guarantee  which  process  would  enter  the  monitor,  if  more  than  one  was  blocked 
outside  it.  For  example,  let  us  assume  that  three  stations  have  to  be  signaled 
from  the  control.  If  one  of  them  is  the  one  that  signaled  the  control  initially 
(i.e.,  it  was  the  last  to  go  to  sleep  from  the  previous  event  cycle),  say  station  3, 
and  the  control  signals  first  the  other  two  stations,  say  1  and  2,  then  there  is  a 
possibility  that  when  the  control  will  try  to  signal  station  3,  one  of  the  first  two, 
say  station  1,  will  have  finished  its  processing,  and  be  blocked  outside  the  moni¬ 
tor.  In  this  case,  signaling  station  3  will  only  take  the  control  outside  the  moni¬ 
tor  and  any  of  the  two  stations,  1  or  3,  which  are  blocked  outside  the  monitor, 
will  be  able,  with  equal  probability,  to  enter  the  monitor.  If  the  station  3  enters 
the  monitor,  everything  will  work  correctly,  since  the  information  that  it  will 
find  is  meant  to  be  for  it.  If  on  the  other  hand,  station  1  enter  the  monitor,  it 
will  take  the  information,  as  if  it  refers  to  it,  resulting  to  an  error. 

An  idea  solving  the  above  problem  is  to  include  the  station’s  ID  in  the  infor¬ 
mation.  Even  so,  another  problem  will  occur  when  multiple  events  will  have  to 
be  handled.  Assume,  for  example,  that  a  multiple  event  is  taking  place  for  a 
station.  (See  in  chapter  3  the  collision  timing  in  a  star  network.)  The  control 
will  signed  the  station  for  the  first  event.  The  station  mil  catch  the  signal, 
enter  the  monitor,  receive  the  information  and  exit.  When  now  the  control 
reenters  the  monitor,  if  the  next  event  refers  to  the  same  station,  it  is  likely 

(  )  The  idea  to  use  indexed  lists,  was  not  considered  as  a  very  good  one,  since  it  would  make 
the  program  code  more  complicated,  and  would  present  a  difficulty  in  handling  the  message 
table. 
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that  the  station  will  be  still  processing  the  first  one.  Thus  the  station  will  not 
be  able  to  catch  the  new  event,  and  when  the  control  enters  the  monitor  and 
places  new  information,  regarding  another  station,  the  previous  information 
will  destroyed,  and  an  event  will  be  lost.  A  solution  for  this  problem  was  to 
include  a  flag  that  informs  the  control  whether  the  information  has  been 
received  or  not.  Although  this  idea  would  work,  we  did  not  And  it  very  efficient, 
since  this  way  the  execution  will  become  too  sequential,  and  the  concurrency 
will  not  be  used  as  well  as  it  can.  The  final  idea  used  was  to  have  a  table  with 
slots,  one  for  each  station,  in  which  the  control  places  the  information  con¬ 
cerning  the  specific  station.  This  way  when  a  station  is  still  processing  the  pre¬ 
vious  event  and  a  new  one  has  to  be  processed,  the  control  will  not  have  to  wait 
for  the  station  to  completes  its  processing,  but  instead  it  will  place  the  informa¬ 
tion  in  the  slot  and  proceed  to  the  next  event.  Whenever  the  station  complete 
its  processing,  it  will  find  a  new  event  in  the  slot,  and  start  processing  it 
immediately.  Only  when  a  third  event  arrives  for  the  same  station,  while  the 
first  one  has  not  been  processed,  the  control  will  have  to  wait. 

The  algorithm  for  the  above  method  is  as  follows. 


Station  No  i. 

Loop 

if  flag (i)  =  0  then 

wait  (condi tion(i)) 
if  flag (i)  =  1  then 

receive  information(i) 

set  flag(i)  =  0 

exit  from  the  monitor 

else 

/*  The  flag  at  this  point  has  the  value  2.  Because  if 
it  was  0,  the  station  would  not  had  been  awakened  V 
receive  information(i) 
set  flag(i)  =  0 
signal  (control) 
exit  from  the  monitor 

end  loop 


Control 

loop 

receive  event(i) 
if  flag(i)  =  0  then 

place  information(i) 
set  flag(i)  =  1 
signal  (condi tion(i)) 

else 


set  flag(i)  =  2 
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wait  (control) 
place  information(i) 
set  flag(i)  =  1 
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6„  The  Single  Class  Simulation  Results. 

In  order  to,  somehow,  verify  that  the  simulation  program  was  correct,  we 
first  obtained  measures  compatible  with  the  analytic  results.  Comparing  the 
results,  we  first  "verified"  the  simulation  correctness,  and,  on  the  other  hand, 
convinced  ourself  that  the  analysis  was  correct.  In  this  chapter  the  single 
priority  class  results  are  given.  Further  results  for  2  priority  classes  appear  in 
the  next  chapter. 


6.1.  Validating  the  Simulation  programs  and  the  Analysis. 

The  model  we  used  for  the  verification,  was  similar  to  the  one  described  in 
[23].  That  is,  a  "star”  network,  (which  is  a  worst  case  network)  with  end  to  end 
propagation  time  a  =0.01  and  without  collision  detection  (6=1).  For  these 
values  of  a  and  b,  the  capacity  is  »0.B15,  when  the  arrival  rate  is  G'  «  9.45  [23], 
The  virtual  clock  rate  for  the  model  was  optimized,  so  that  G'=r]G  [23],  while 
the  collide  messages  were  retransmitted  with  a  geometrically  distributed  delay 
of  mean  «3  (*).  (This  is  equivalent  to  a  minislotted  protocol  with  transmission 
probability  of  «0. 166xl0-3  per  minislot.)  Finally  the  stations  had  a  finite  buffer 
size  of  15,  and  each  message  was  allowed  16  transmissions,  before  been  dis¬ 
carded. 

In  Figure  6.1  we  compare  the  theoretical  throughput  -  delay  curve,  with 
the  simulation  result.  As  we  easily  see,  the  two  curves  are  consistent  and  thus 
we  have  an  indication  of  the  correctness  of  both  the  analysis  and  the  simula¬ 
tion. 


In  Figure  6.2  the  throughput,  in  terms  of  the  offered  load,  is  given,  com¬ 
bined  with  the  percentage  of  blocked  messages  (due  to  buffer  overflow).  Note 
that  no  discarding  of  messages  (due  to  excessive  number  of  collisions)  was 
observed.  An  interesting  thing  to  note,  is  the  way  that  the  offered  load  is  regu¬ 
lated.  Up  to  capacity  («81%),  the  throughput  increases  linearly  with  the  offered 
load.  At  capacity,  the  excess  load  is  blocked,  so  that  the  finally  offered  bring 
the  system  just  at  capacity  (|). 

Finally  in  Figure  6.3  the  average  number  of  transmissions  per  message  is 

( #)  The  above  backoff  algorithm  will  be  referenced  from  now  on  as  random  re  transmissions 
algorithm. 

(tj  At  this  point  the  analysis  can  show  that  since  the  channel  utilization  remains  fixed  and 
the  number  of  messages  in  the  system  cannot  exceed  a  maximum  number  (i.e. ,  number  of 
stations  X  buffers  per  station),  the  delay  will  not  increase  indefinitely.  In  our  case,  the  max 
imum  number  of  messages  in  the  system  is  300,  and  the  chann^^jitilization  is  «0.81.  That 
means  that  the  maximum  delay,  given  from  Little  s  law,  will  be  q  qj  w  370. 
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Figure  6.1,  Throughput  -  Delay  trade  offs  for  the 
theoretical  and  simulated  models. 
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Figure  6.2.  Load  -  Throughput  &  Blocking  trade  offs 
for  the  simulated  model. 
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Figure  6.3.  Average  message  transmissions  for  the 
simulated  model. 
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given.  As  it  can  be  seen,  the  average  number  of  transmissions  per  message  is 
increasing  with  the  throughput,  and  at  capacity  it  decreases.  Again  this  is  due 
to  the  finite  buffer  size  of  the  station.  Since  the  number  of  messages  in  the 
system  is  kept  constant,  while  the  delay  increases,  it  is  more  probable  for  a 
message  to  be  successfully  transmitted  in  the  next  transmission.  (Remember 
that  for  a  given  throughput,  we  can  decrease  the  number  of  transmissions  per 
message,  if  we  increase  the  retransmission  delay.)  Also  in  high  load  the  offered 
traffic  is  regulated  through  collisions  and  retransmissions  in  such  &  way,  that  it 
becomes  more  deterministic,  losing  its  Poisson  characteristics.  Obviously  such 
a  traffic  will  result  to  an  improved  performance. 

6.2.  The  Virtual  Clock  Rate  Effect. 

The  new  idea  presented  with  the  VT-CSMA  protocol,  was  the  notion  of  the 
virtual  clock.  Since  the  virtual  clock  runs,  in  general,  faster  than  real  time, 
the  obvious  question  is,  what  are  the  effects  of  the  virtual  clock's  speed  to  the 
performance  of  the  protocol.  In  order  to  answer  this  question,  a  "star"  network 
with  propagation  delay  0.1  (=a),  was  simulated.  The  number  of  stations  in  the 
network  was  20,  each  of  which  had  a  buffer  of  size  15.  The  messages  were 
allowed  16  transmissions  before  being  discarded.  The  backoff  algorithm  was  the 
"random  retransmissions"  one,  with  mean  3.333  .  When  collision  detection 
existed,  the  recovery  time  was  0.01  (=6).  For  these  values  of  a  and  b ,  the  capa¬ 
city  is  »0.'65  and  »0.52  [23],  for  the  cases  with  and  without  collision  detection 
(b  =0.01  and  6=1,  respectively). 

In  Figure  6.4  the  throughput  and  the  discarded  percentage  of  messages  for 
different  values  of  load  is  given,  for  the  cases  where  the  virtual  clock  rate  is  5, 
7,  9,  11,  15  and  the  collision  detection  exists.  In  Figures  6.5  -  6.6,  the  offered 
load  is  fixed  at  60%,  and  the  parameter  is  the  virtual  clock  rate.  When  collision 
detection  exists  (Figure  6.5),  the  performance  of  the  protocol  is  improving  with 
the  virtual  clock  rate.  Note  that  in  this  case,  the  protocol  operates  below  capa¬ 
city  (65%).  When  collision  detection  does  not  exist  (Figure  6.6),  the  network  is 
overloaded  (capacity  a  52%).  In  this  case  there  exists  an  optimal  virtual  clock 
rate  [23]  at  which  the  network  reaches  its  capacity.  In  our  case  the  optimal 
virtual  clock  rate,  as  calculated  from  the  analysis,  is  a  2.6,  which  is  in  very 
good  agreement  with  the  simulation  results.  Above  this  optimal  virtual  clock 
rate,  the  protocol’s  performance  degrades  as  it  becomes  unstable.  Note  that 
due  to  the  finite  buffer  size,  when  the  network  is  overloaded,  the  blocking  effect 
taking  place  will  regulate  the  incoming  load  to  exactly  the  one  that  the  network 
can  handle.  Even  so,  as  it  can  be  seen  in  Figure  6.6,  when  the  virtual  clock  rate 
increases  above  the  optimal  point,  the  discarded  messages  are  increasing,  and 
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Figure  6.4.  The  Virtual  Clock  rate  effects  in  the 
Throughput  and  Discarding  in  a  network 
with  collision  detection. 
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Figure  6.5.  Throughput  &  Discarding  for  variable 
clock  rate  and  fixed  load  in  a  network 
with  collision  detection. 
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Figure  6.6.  Virtual  Clock  rate  effects  in  a  network 
without  collision  detection.  Throughput, 
Discarding  and  Blocking. 
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the  protocol  collapses. 

Figures  6.7  -  6.8  present  the  average  packet  delay,  in  terms  of  the  virtual 
clock  rate,  for  the  two  previous  cases  where  collision  detection  exists  and  does 
not  exist,  respectively.  When  collision  detection  exists  (Figure  6.7),  the  proto¬ 
col  is  stable  for  the  offered  load  of  60%,  and  the  increase  of  the  virtual  clock 
rate  simply  improves  the  delay  characteristics.  On  the  other  hand,  when  colli¬ 
sion  detection  does  not  exist  (Figure  6.8),  the  protocol  is  unstable,  and  for 
values  of  the  virtual  clock  rate  above  the  optimal,  the  delay  increases  to 
"infinity". 

Finally  in  Figures  6.9  -  6.10,  the  transmissions  per  message  are  given,  for 
the  above  two  cases.  Again  when  the  protocol  is  stable  (Figure  6.9),  the  average 
transmissions  per  message  are  improving  with  the  virtual  clock  rate,  while  in 
the  unstable  case  (Figure  6.10),  they  increase  to  reach  "infinity".  Note  that 
when  the  virtual  clock  rate  goes  to  1,  we  expect  the  average  transmissions  per 
message  to  decrease.  (It  only  goes  to  1  as  the  Virtual  Clock  rate  goes  to  0!)  But, 
as  it  can  be  seen  from  figure  6.5,  due  to  the  finite  buffer  size  in  the  stations,  the 
blocking  probability  will  go  to  1,  and  the  throughput  to  0.  Thus  tests  for  values 
of  the  virtual  clock  near  1,  would  be  meaningless. 

The  above  results  can  easily  be  explained,  if  we  consider  the  fact  that  in 
high  virtual  clock  rates,  the  protocol  tends  to  become  equivalent  with  the  1- 
persistent.  In  fact,  in  the  case  without  collision  detection,  the  results  come  to 
agreement  with  the  performance  analysis  of  the  1-persistent  protocol,  given  by 
Kleinrock  and  Tobagi  in  [16]. 

In  order  to  explain  the  irregularities  observed  in  Figures  6.7  and  6.9,  addi¬ 
tional  tests  were  performed  for  a  "bus"  network.  (Remember  that  the  previous 
results  concerned  a  "star"  network.)  This  way  we  were  able  to  verify  that  the 
irregularities  were  not  due  to  the  special  "star"  topology,  but  are  a  characteris¬ 
tic  of  the  virtual  clock  idea.  The  model  used  for  these  tests  was  a  bus  with  21 
stations  equally  spaced  with  an  inter-station  propagation  time  of  0.005  (thus 
the  end  to  end  propagation  time  was  0.1).  The  collision  recovery  time  was  0.2 
(round  trip  end  to  end  propagation  time).  The  offered  load  for  this  model  was 
fixed  to  63%.  The  rest  of  the  network  parameters  were  the  same  as  previously. 

Figures  6.11-6.13  present  the  performance  of  the  above  bus  network  for 
different  virtual  clock  rates.  In  figure  6.11  the  throughput,  discarding  and 
blocking  are  given.  It  interesting  to  observe  the  behavior  of  the  blocking  proba¬ 
bility,  as  a  function  of  the  virtual  clock  rate.  As  it  can  be  seen,  blocking 
appears  only  for  a  specific  range  of  virtual  clock  rates.  For  this  range  of  virtual 
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Figure  6.7.  Virtual  Clock  rate  effects  in  a  Star  Net¬ 
work  with  collision  detection. 
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Figure  6.8.  Virtual  Clock  rate  effects  in  a  Star  Net¬ 
work  without  collision  detection. 
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Figure  6.9.  Virtual  clock  rate  effects  in  the  average 
transmissions  per  message,  for  a  Star 
Network  with  collision  detection. 
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Figure  6.10  Virtual  Clock  rate  effects  in  the  average 
transmissions  per  message,  for  a  btar 
Network  without  collision  detection. 
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Figure  6.11.  Virtual  Clock  rate  effects  in  the 
Throughput  of  a  Bus  Network  with  colli¬ 
sion  detection. 
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Figure  6.12.  Virtual  clock  rate  effects  in  the  Delay  of 
a  Bus  Network  with  collision  detection. 
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Figure  6.13.  Virtual  clock  rate  effects  in  the  average 
transmissions  per  message,  for  a  Bus 
Network  with  collision  detection. 
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clock  rate,  from  figures  6.12  and  6.13,  we  see  that  we  have  a  peak  in  the  average 
message  delay  and  transmissions  per  message,  respectively. 

The  irregularities  observed  in  the  "star”  topology  (Figures  6.7,  6.9),  are 
also  present  to  in  the  "bus"  topology,  with  the  only  difference  that  in  the  "bus" 
network  the  curves  seem  to  be  stretched,  in  reference  to  the  virtual  clock  rate 
axis.  Also,  obviously  because  the  "bus"  model  operates  near  capacity,  the 
effects  of  the  virtual  clock  rate  are  visible  in  the  throughput  curves  (figure 
6.11).  Considering  figures  6.7,  6.9,  6.11-6.13,  we  can  now  give  a  "reasonable" 
explanation  for  the  irregularities  observed. 

For  virtual  clock  rate  near  1,  the  protocol  operates  with  "infinite"  delay 
and  the  blocking  probability  is  near  1.  The  throughput  achieved  for  that  virtual 
clock  rate  is  near  zero,  independently  of  the  offered  load.  As  the  virtual  clock 
rate  increases  reaching  the  optimal  value,  (as  described  in  [23])  the  perfor¬ 
mance  of  the  protocol  will  improve.  Because  for  these  values  of  the  virtual 
clock  rate,  the  virtual  clock  will  (in  general)  run  beyond  real  time,  as  the  rate 
increases  the  delay  on  the  one  hand,  will  decrease,  while  on  the  other  hand,  the 
collision  probability  will  increase  (since  the  observable  -offered  load  will 
increase).  At  some  point  the  effect  of  the  increasing  collision  probability  will 
overrun  the  decreasing  delay,  and  the  protocols  performance  will  start  decay¬ 
ing.  This  point  is  the  optimal  operating  point  described  in  [23].  For  values  of 
the  virtual  clock  above  the  optimal,  the  average  number  of  collisions  per  mes¬ 
sage  will  start  increasing,  leading  to  high  values  of  retransmissions  per  mes¬ 
sage,  and  thus  to  increased  blocking  probability.  As  a  result  the  message  delay 
will  also  increase.  On  the  other  hand,  the  virtual  clock  will  start  running  with 
real  time  more  often,  thus  tending  to  decrease  the  collision  probability.  When 
the  fraction  of  time  at  which  the  virtual  clock  runs  with  real  time  is  big 
enough,  the  collision  probability  will  start  decreasing,  and  an  improvement  to 
the  protocols  performance  will  be  observed.  When  the  virtual  clock  rate  will  be 
high  enough  so  that  the  virtual  clock  to  catch  up  with  real  time  after  a  colli¬ 
sion,  but  not  after  a  successful  transmission,  the  performance  will  stabilize. 
For  higher  values  of  the  virtual  clock  rate,  the  virtual  clock  will  start  catching 
up  with  real  time  even  after  a  successful  transmission,  and  a  further  improve¬ 
ment  will  be  observed.  For  very  high  values  of  the  virtual  clock,  the  protocol 
tends  to  become  equivalent  to  the  1-persistent,  which  is  known  to  have  a  lower 
performance.  Thus  for  very  high  values  of  the  virtual  clock  rate,  the  protocols 
performance  will  stabilize  to  the  one  achieved  with  the  1-persistent.  Before 
reaching  1-persistent,  there  should  be  a  "bump"  where  we  get  all  the  collisions 
as  1-persistent  but  not  as  well  overlapping.  Unfortunately  we  were  not  able  to 
give  a  good  explanation  for  the  irregularities  observed  in  the  intermediate 
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values. 

6.3.  Retransmission  Strategies. 

One  of  the  advantages  of  the  VT-CSMA  protocol,  is  that  it  can  be  combined 
with  a  variety  of  backoff  algorithms,  giving  the  possibility  of  improved  perfor¬ 
mance  [20].  In  order  to  obtain  exact  results  about  different  retransmission 
strategies,  our  simulation  models  retransmission  strategies  in  detail.  Three 
basic  retransmission  strategies  are  considered.  First,  the  truncated  binary 
exponential  back-off  algorithm  [19, 17]  used  in  the  Ethernet  is  tested.  With  this 
algorithm,  after  k  previous  collisions  a  message  is  discarded  if  A:  >  16;  otherwise 
its  next  retransmission  will  be  delayed  uniformly  over  the  range 
(0, 2mln^te,0^x2a),  where  a  is  the  the  end-to-end  propagation  delay  for  the  net¬ 
work. 

The  second  strategy  is  based  on  the  work  of  Field  and  Wong  [11].  Here  the 
delay  until  the  next  retransmission  is  geometrically  (rather  than  uniformly) 
distributed.  With  this  retransmission  strategy,  the  virtual  clock  rate  was 
adjusted  as  a  function  of  throughput  (see  below).  Thus,  since  the  retransmis¬ 
sion  times  were  chosen  with  respect  to  virtual  time,  the  mean  of  this  distribu¬ 
tion  was  indirectly  adjusted  as  a  function  of  throughput.  However,  we  did  not 
consider  choosing  the  mean  as  a  function  of  the  number  of  attempts  per  mes¬ 
sage. 

The  third  retransmission  strategy  that  was  evaluated  is  called  an  asyn¬ 
chronous:  stack  algorithm  [24\.  Asynchronous  stack  algorithms  are  an  exten¬ 
sion  of  the  synchronous  stack  algorithm  of  Tsybakov  and  Vvedenskaya  [31], 
which  in  turn  is  an  extension  of  Capetanakis-style  tree  algorithms.  Here  the 
positions  of  messages  in  the  ‘stack’  may  be  viewed  as  points  in  a  segment  of  the 
read  line,  rather  than  discrete  (integer)  values.  Whenever  the  channel  is 
sensed  idle,  each  station  'pops'  (shortens)  its  stack  continuously  at  unit  speed 
until  either  the  channel  becomes  busy  or  a  message  reaches  the  top  and  is 
transmitted.  Whenever  a  collision  occurs,  each  stack  is  'pushed  down' 
(lengthened)  by  some  fixed  amount,  T  say.  Those  messages  that  were  involved 
in  that  collision  are  reassigned  at  random  to  some  position  less  them  T.  Here 
we  consider  two  versions.  For  the  first  version,  we  carry  out  the  reassignment 
uniformly  over  the  range  (0,  T ).  The  constant  T  must  be  chosen  so  that  the 
probability  of  a  repeat  collision  between  two  messages  is  below  0.5,  as  it  was  in 
the  synchronous  stack  algorithm.  In  the  experiments  below,  both  7,=0.5  and 
T^O.l  were  tested.  For  the  second  version,  we  let  jT=4a=0.04  and  carry  out  the 
reassignment  so  that  colliding  messages  are  assigned  either  to  the  top  of  the 
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stack  or  to  position  2a  with  equal  probability.  For  this  ‘optimized’  version,  we 
have  avoided  a  random  enforced  idle  time  before  the  first  retransmission 
begins  and  also  managed  to  reduce  the  total  amount  by  which  the  stack  is 
pushed  down  following  a  collision  without  increasing  the  probability  of  two  mes¬ 
sages  suffering  a  repeat  collision  beyond  0.5. 

For  the  following  results,  the  model  used  was  a  20  station  "star"  network 
with  propagation  time  a  =  0.01,  while  the  collision  recovery  time  was  b  =0,001 
(when  it  existed). 

Figures  6.14—6.16  show  the  dependence  of  throughput  and  blocking  proba¬ 
bility  on  the  offered  load  for  various  combinations  of  protocol  and  retransmis¬ 
sion  strategy.  Recall  that  in  all  cases,  our  model  contains  20  stations,  each 
having  a  packet  buffer  of  size  15,  and  that  our  simulation  lasted  for  20,000  time 
units. 

In  Figure  6.14,  we  compare  virtual  time  CSMA  and  1-persistent  CSMA 
without  collision  detection  when  the  random  geometric  retransmission  stra¬ 
tegy  is  used.  The  speed  of  the  virtual  clock  in  virtual  time  CSMA  is  optimized  as 
a  function  of  offered  load  so  that  the  'effective'  offered  load  (i.e.,  the  true 
offered  load  multiplied  by  the  virtual  clock  speed)  remains  constant  over  all 
values  of  offered  load.  This  constant,  ^9.45,  was  found  in  [22]  as  the  offered 
load  at  which  the  Poisson  model  of  asynchronous  virtual  time  CSMA  attains  its 
highest  efficiency  when  a  =  .01  and  there  is  no  collision  detection.  The  mean  of 
the  retransmission  distribution  was  3  time  units  for  virtual  time  CSMA  and  100 
for  1-persistent  CSMA  (here  lesser  values  led  to  instability  very  quickly). 

The  results  here  show  three  things.  First,  both  protocols  work  properly  in 
the  sense  that  all  messages  are  delivered  as  long  as  the  load  remains  below  the 
capacity  of  the  system.  Second,  1-persistent  CSMA  reaches  its  capacity  much 
earlier  than  does  virtual  time  CSMA  Third,  the  stability  of  1-persistent  CSMA  is 
much  more  sensitive  to  overload  and  hence  the  choice  of  retransmission  stra¬ 
tegy  here  is  more  critical.  When  1-persistent  CSMA  is  overloaded,  its  perfor¬ 
mance  degrades  suddenly  as  throughput  drops  and  blocking  increases.  For  vir¬ 
tual  time  CSMA  the  throughput  levels  off  and  excess  load  is  simply  blocked  as 
the  station  buffers  overflow. 

In  Figure  6.15,  we  plot  throughput  and  the  probabilities  of  blocking  and 
rejection  as  a  function  of  load  for  several  algorithms  with  collision  detection. 
We  find  that  for  virtual  time  CSMA  with  fixed  virtual  clock  speed  of  10,  there  is 
no  difference  in  these  statistics  for  any  of  the  retransmission  strategies  we  con¬ 
sidered,  namely  the  truncated  binary  exponential  algorithm  and  three  varia- 
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Figure  6.14.  1-Persistent  -  Random  retransmissions 
algorithm  comparison.  Throughput, 
Blocking  &  Discarding. 
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Figure  6.15.  Throughput  comparison  for  the  trun¬ 
cated  Binary  exponential  and  asynchro¬ 
nous  stack  algorithms. 
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Figure  6.16.  Throughput  comparison  of  the  1- 
Persistent  Binary  Exponential  algo¬ 
rithm,  and  the  improved  asynchronous 
stack  algorithm. 
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tions  of  the  asynchronous  stack  algorithm.  In  addition,  we  find  the  same 
results  also  hold  for  the  random  geometric  retransmission  strategy  where  we 
adjust  the  virtual  clock  rate  as  a  function  of  load  as  described  above.  (We  note 
that  the  here,  too,  the  clock  rate  is  approximately  10  when  the  load  is  near 
saturation.)  These  results  suggest  that  since  the  choice  of  retransmission  stra¬ 
tegy  has  little  effect  on  the  stability  and  attainable  throughput  of  the  protocol, 
then  perhaps  some  other  parameter  of  the  algorithm  (like  the  virtual  clock 
rate)  could  be  tuned  to  some  less  conservative  value. 

In  Figure  6.16,  we  investigate  the  effect  of  varying  the  virtual  clock  speed. 
Here  again  we  show  the  throughput  vs.  load  curve  for  the  optimized  stack  algo¬ 
rithm  when  the  clock  speed  equals  10.  However,  two  more  curves  are  also 
shown:  the  same  optimized  stack  algorithm  when  the  clock  speed  is  doubled, 
and  an  'ethernet-type'  strategy  combining  1-persistent  CSMA  (i.e.,  setting  the 
clock  speed  to  infinity)  and  the  truncated  binary  exponential  back-off  algo¬ 
rithm.  Here  we  find  that  both  algorithms  where  the  virtual  clock  speed  is 
increased  attain  higher  throughput  values,  but  that  the  optimized  stack  algo¬ 
rithm  with  clock  speed  of  20  gives  the  best  performance  because  its  maximum 
throughput  is  highest  and  this  value  is  obtained  by  discarding  or  rejecting 
fewer  messages  than  either  of  the  other  two  strategies. 

In  Figure  6.17,  we  show  the  throughput  vs.  delay  performance  for  the  same 
configurations  as  were  included  in  Figure  6.15.  The  delays  for  all  strategies 
converge  at  saturation,  but  there  are  significant  differences  under  light  load. 
Tndeed  the  mean  delay  improves  monotonically  as  we  'tighten'  the  retransmis¬ 
sion  strategy:  the  throughput-delay  performance  of  the  optimized  stack  algo¬ 
rithm  with  push-down  4a  =  0.04  is  uniformly  better  than  the  first  version  of  the 
stack  algorithm  with  push-down  0.1,  which  is  uniformly  better  than  the  first 
version  of  the  stack  algorithm  with  push-down  0.5.  The  performance  of  virtual 
time  CSMA  with  the  truncated  binary  exponential  back-off  algorithm  are  very 
similar  to  the  optimized  stack  algorithm.  This  seems  reasonable  because  both 
the  mean  and  variance  of  the  number  of  attempts  remains  small  at  all  times 
for  both  strategies  (less  than  1.4  and  1.0,  respectively,  for  the  optimized  stack 
algorithm,  and  less  than  1.3  and  0.7,  respectively,  for  the  truncated  binary 
exponential  back-off  algorithm),  so  that  there  is  really  little  difference  in  the 
two  retransmission  strategies  in  this  situation.  Similar  results  hold  for  the 
delay  variance  —  see  Figure  6.18.  This  again  suggests  that  either  the 
retransmission  strategy  or  other  system  parameters  (such  as  virtual  clock 
speed)  can  be  further  tuned  to  improve  performance. 

In  [22,21],  simple  models  of  virtual  time  CSMA  based  on  the  Poisson  total 
traffic  approximation  were  presented.  Here  we  compare  these  predictions  with 
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Figure  6.17.  Delay  comparison  for  different  backoff 
algorithms. 
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Figure  6.18.  Delay  variance  comparison  for  different 
backoff  algorithms. 
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the  results  of  our  simulation  study. 

In,  the  analytic  model,  the  total  traffic  (including  both  new  and  retransmit¬ 
ted  messages)  forms  a  Poisson  process  with  intensity  G  per  unit  time.  Because 
of  collisions,  the  throughput,  S,  will  always  be  less  than  G.  However,  it  is 
assumed  that  colliding  messages  are  always  retransmitted  until  they  are 
retransmitted  successfully,  which  requires  G/ S  attempts,  on  average.  Thus 
the  analysis  predicts  that  the  throughput  should  equal  the  load  up'to  some  lim¬ 
iting  value  we  call  the  capacity  (*)  of  the  protocol. 

This  exact  behavior  was  observed  in  the  simulation  of  virtual  time  CSMA. 
The  maximum  throughput  values  observed  in  Figure  6.14  are  in  close  agree¬ 
ment  with  the  published  values  of  ^0.529  for  1-persistent  CSMA  [16]  and  ^0.815 
for  virtual  time  CSMA  [22]  when  a  =0.01  and  there  is  no  collision  detection. 
With  collision  detection,  we  did  not  optimize  virtual  clock  speed,  but  instead 
chose  clock  speeds  of  10  and  20  for  our  experiments.  (Analysis  suggests  that 
for  this  situation,  maximum  capacity  of  «0.95  is  obtained  with  a  virtual  clock 
rate  near  50.)  With  these  lesser  values  of  clock  speed,  we  reach  capacity  not 
because  we  saturate  the  channel,  but  rather  because  the  virtual  clock  cannot 
keep  up  with  real  time  during  the  small  amount  of  channel  idle  time  so  that 
queueing  delays  for  the  messages  grow  without  bound.  It  can  be  shown  [22] 
that  for  the  ’star’  topology  with  virtual  clock  speedy,  propagation  time  time  a, 
and  collision  recovery  time  6,  the  expected  duration  of  a  'transmission  cycle’ 
for  virtual  time  CSMA  is  given  by 

2a  +  b(l -e-^+e-^il/rjG-l),  (6.1.) 

during  which  the  virtual  clocks  run  for  an  average  time  of  1/rjG  +  a  so  as  to 
advance  by 

1/G+rja.  (6.2.) 

Thus  capacity  for  fixed  virtual  clock  speed  is  found  by  equating  Eqs.  (6.1.)  — 
(6.2.)  to  find  the  load  at  capacity,  G* ,  and  then  evaluating  the  throughput  equa¬ 
tion  for  virtual  time  CSMA  [22]  at  G* .  We  find  the  capacities  should  be  w.90  and 
w.93,  respectively,  when  the  virtual  clock  speeds  are  10  and  20.  Again  these 
results  are  in  very  close  agreement  with  the  simulation  results. 

Finally,  the  analysis  predicts  that  the  average  number  of  attempts  per 
message  should  be  about  G/  S.  Given  virtual  clock  speed  10,  propagation  time 
a=0.01,  and  collision  recovery  time  6=0.001,  the  analytical  prediction  states 
that  the  number  of  attempts  should  grow  to  about  1.14  at  saturation, 

(  )  More  precisely,  capacity  is  the  supremum  over  all  arrival  rates  such  that  the  expected 
message  delay  remains  finite. 
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corresponding  to  a  throughput  of  about  0.90.  This  predicted  curve  is  shown  in 
Figure  6.19.  The  corresponding  simulation  results  for  the  three  versions  of  the 
stack  algorithm  with  virtual  clock  speed  10  are  also  shown.  For  the  ‘unoptim- 
ized'  versions  of  the  stack  algorithm,  the  experimental  results  for  push-down 
intervals  of  0.5  and  0.1  are  indistinguishable  within  some  confidence  interval: 
the  average  number  of  attempts  per  message  grew  monotonically  to  1.24  at 
saturation  (i.e.,  a  throughput  of  about  0.90).  These  curves  match  the  predicted 
values  almost  exactly,  a  strong  indication  that  the  analytic  resillts  from  the 
Poisson  model  provide  a  useful  insight  into  the  true  behavior  of  these  systems. 
For  the  optimized  stack  algorithm,  the  fit  is  significantly  worse.  Here  the  shape 
of  the  number  of  attempts  vs.  throughput  curve  seems  similar  to  the  predicted 
value  when  the  system  is  operating  below  capacity  except  for  a  multiplicative 
factor.  This  is  to  be  expected,  since  the  stack  algorithm  ’learns’  from  these 
unsuccessful  attempts  and  thus  the  presence  of  some  collisions  merely  indi¬ 
cates  that  the  algorithm  is  working  properly.  However,  the  sharp  drop  in  the 
average  number  of  attempts  near  saturation  seems  quite  unexpected.  At 
present,  we  have  no  convincing  explanation  of  this  effect;  it  remains  a  topic  of 
active  investigation.  However,  we  conjecture  that  its  cause  is  that  at  satura¬ 
tion,  the  Poisson  assumption  upon  which  the  analysis  is  based  fails  to  give  a 
useful  characterization  of  the  load.  Indeed  the  output  of  retransmitted  mes¬ 
sages  from  the  optimized  stack  tends  to  look  like  an  almost  deterministic  pro¬ 
cess,  which  should  reduce  the  relative  number  of  collisions  on  the  channel  for  a 
given  throughput  value. 

6.4.  The  VT-CSMA  protocol  in  Ethernet. 

The  VT-CSMA  is  not  an  abstract  protocol  used  for  obtaining  only  perfor¬ 
mance  values  through  theoretical  analysis,  but  a  highly  practical  and  applica¬ 
ble  one,  able  to  compete  with  existing  protocols  in  real  networks.  One  well- 
known  network,  operating  in  North  America,  is  the  Ethemet[\l,  19, 33].  The 
Ethernet  operates  under  the  CSMA/CD  protocol,  which  is  really  1-persistent 
CSMA  with  truncated  binary  exponential  algorithm,  described  in  the  previous 
section.  The  wire  speed  is  10  Mbits/sec,  while  channel  sensing  and  collision 
detection  are  provided.  The  performance  of  the  Ethernet,  as  described  above, 
has  been  studied  by  Marathe  [17]  for  different  backoff  algorithms.  In  his  termi¬ 
nology,  the  binary  exponential  algorithm  is  referenced  as  standard  wire, 
Marathe  has  obtained  results  for  the  10  Mbits/sec  wire,  in  a  bus  network  with 
end-to-end  propagation  time  of  32 fiS.  Two  sizes  of  packets  were  tested.  A  short, 
with  280  bytes  (=2240  bits),  and  a  long  one  with  10,000  bytes  (  =  80,000  bits). 
From  his  results,  Marathe  concluded  that  for  the  tested  backoff  algorithms  the 
standard  wire  behaves,  in  general,  at  least  as  well. 
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Figure  6.19.  Average  message  transmissions  for  the 
different  versions  of  the  asynchronous 
stack  algorithm. 
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For  the  VT-CSMA  protocol  we  first  tried  to  validate  Marathe’s  results  and 
then  compare  them  with  the  asynchronous  stack  algorithm,  described  also  in 
the  previous  section. 

Before  proceeding  and  presenting  our  results,  we  must  first  make  some 
remarks  about  Marathe's  results  [17].  In  his  paper,  and  for  the  cases  with  short 
and  long  packets  (Tables  6-7  and  Figures  6-7  respectively  in  [17],  also  included 
in  the  appendix  of  this  work),  the  results  seem  to  be  inconsistent  or  at  least, 
not  well  described. 

In  Tables  6-7  the  delay  results  are  given  in  terms  of  the  ratio  of  offered. 
Load  over  capacity  without  mentioning  which  is  the  capacity  in  these  cases  (i.e., 
the  raw  bit  rate  of  the  channel,  or  the  maximum  attainable  throughput  with  the 
given  protocol).  On  the  other  hand,  in  Figures  6-7  the  delay  is  given  in  terms  of 

the  offered  load  in  Mbits /sec.  This  way  it  is  rather  difficult  to  combine  the 

/ 

tables  with  the  figures.  In  an  attempt  to  understand  these  results,  we  took  as 
capacity  the  10  Mbits/sec  wire  speed.  That  meant  that  the  0.4  load/capacity  in 
Table  6,  is  simply  a  4  Mbits/sec  load.  The  service  time  for  this  "load",  is  given 
as  404^5,  for  the  standard  wire.  In  Figure  6,  for  load  of  4  Mbits /sec,  the  service 
time  is  less  than  400 pS.  So  the  results  are  at  least  inconsistent. 

On  the  other  hand,  for  an  offered  load  of  7  Mbits/sec,  in  Table  6  and  Figure 
6  again,  the  aborted  packets  for  the  standard  wire  are  0.2%  of  the  successful 
ones.  That  means  that  the  throughput  in  this  case  would  be  »7Q%.  The  delay 
found  for  this  case  was  937 pS,  or  normalized  ^5.  Considering  now  that  the 

32 

end-to-end  propagation  delay  fraction  (a)  is  ^^-«0.14  ,  no  matter  how  optimis¬ 
tic  the  results  may  be,  they  come  in  complete  disagreement  with  all  the  previ¬ 
ous  analysis  [16]. 

In  our  simulation  model  the  network  was  consisting  of  21  stations  in  a  bus 
channel,  with  inter-propagation  delay  of  1.6/iS  (so  the  end-to-end  propagation 
delay  =  20x1.6  =  32/xS).  Each  station  has  buffer  capable  of  holding  up  to  15 
packets.  Each  packet  is  allowed  to  be  retransmitted  up  to  16  times  and  then  it 
is  aborted  (discarded).  The  collision  detection  feature  exists  and  after  a  colli¬ 
sion  the  channel  is  jammed  by  the  station  for  64 pS  (the  round  trip  propagation 
delay),  so  that  all  stations  are  able  to  identify  the  collision  [11].  The  backoff 
algorithms,  as  already  mentioned,  were  the  truncated  binary  exponential  and 
the  asynchronous  stack  algorithm.  The  binary  exponential  was  combined  with 
the  1-persistent  idea,  which  can  be  implemented  via  the  VT-CSMA  [23,24].  For 
the  stack  algorithm  the  "optimized"  version  (see  previous  section)  [20]  was 
used  with  two  different  clock  rates  for  the  two  cases  with  short  and  long  mes- 
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sages.  That  is,  an  average  clock  rate  of  10  was  tested  for  both  cases,  and  a 
"near  optimal"  one.  We  say  "near  optimal"  because  of  the  difficulty  in  finding 
an  optimal  one.  The  reason  is  that  the  optimality  conditions,  described  in  [23], 
apply  for  a  "star"  topology  where  the  propagation  delay  is  fixed  for  all  stations. 
In  our  case  we  have  a  "bus”  topology,  and  the  propagation  delay  differs  for  each 
pair  of  stations.  In  order  to  bypass  this  problem,  we  calculated  the  optimal 
working  point  using  the  average  propagation  delay  among  the  stations.  This 
way  the  "optimal"  virtual  clock  rate  for  the  short  message  case  was  ^4.9  with  a 
maximum  throughput  of  »70%,  while  for  the  long  message  case  the  "optimal" 
virtual  clock  rate  was  «  172  with  a  maximum  throughput  of  «  98%.  For  our  tests 
we  set  the  virtual  clock  rates  to  5  and  171  (*),  for  the  short  and  long  message 
cases,  respectively. 

In  Figures  6.20-6.24,  performance  measures  for  the  case  with  short  mes¬ 
sages  (280  bytes)  are  given,  while  Figures  6.25-6.28  present  performance  meas¬ 
ures  for  long  messages  (10,000  bytes). 

Figures  6.20,  6.21  give  the  throughput  achieved  by  the  algorithms  and  the 
corresponding  aborted  percentage  of  messages,  in  terms  of  the  offered  load, 
respectively.  We  can  easily  see  that  at  load  w  5  Mbits/ sec,  the  binary  exponen¬ 
tial  algorithm  leads  to  instability.  On  the  other  hand,  the  stack  algorithms 
remain  stable,  as  approach  capacity  («70%).  Note  that  the  throughput 
achieved  with  the  "optimal"  stack  algorithm,  is  better  than  the  one  achieved 
with  the  "unoptimized"  algorithm.  Figure  6.22  gives  the  average  delay  time,  in 
terms  of  the  offered  load  (Mbits /sec).  As  it  can  be  seen,  the  stack  algorithm 
with  "optimal"  virtual  clock  rate  gives  smaller  delay  from  both  the  binary 
exponential  and  the  "unoptimized"  stack.  Figure  6.23  gives  the  delay  variance 
for  the  the  two  backoff  algorithms.  Again  the  "optimal"  stack  algorithm 
behaves  better  than  the  other  two.  Finally  Figure  6.24  gives  the  average 
number  of  transmissions  per  message,  for  the  two  algorithms.  As  it  can  be 
seen,  the  transmissions  per  message  for  the  "optimal"  stack  algorithm,  are  less 
than  both  the  other  two  algorithms.  From  the  above  results  we  can  say  that  the 
Virtual  Time  CSMA  protocol  behaves  better  than  the  1-Persistent  Binary 
Exponential  in  an  Ethernet  environment,  when  the  traffic  is  due  to  short  mes¬ 
sages. 

For  the  long  message  case  (10,000  bytes)  the  problem  of  selecting  the 
optimal  virtual  clock  rate  was  more  difficult  to  be  solved.  That  was  because  the 
propagation  fraction  a,  had  a  very  small  value  (0.004)  and  its  selection  had  to 
be  done  in  an  almost  arbitrary  way,  as  described  above.  This  way  a  change  in 

( *)  See  following  discussion  about  the  long  message  "optimal"  Virtual  Clock  rate. 
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Figure  6.20.  Throughput  for  the  standard  Ethernet 
and  the  asynchronous  backoff  algo¬ 
rithms. 
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Figure  6.21.  Blocking  and  Discarding  for  the  Stan¬ 
dard  Ethernet  and  the  asynchronous 
backoff  algorithms. 


Figure  6.22.  Delay  comparison  of  the  the  standard 
Ethernet  backoff  algorithm  and  the 
asynchronous  stack  algorithm  with  two 
virtual  clock  rates. 
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Figure  6.23.  Delay  Variance  for  the  Standard  Ether¬ 
net  and  the  asynchronous  stack  algo¬ 
rithm  with  two  virtual  clock  rates. 
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Figure  6.24.  Average  message  transmissions  for  the 
Standard  Ethernet  and  the  asynchro¬ 
nous  stack  algorithm  with  two  virtual 
clock  rates. 
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its  value  would  resulted  in  a  great  change  in  the  "optimal"  virtual  clock  rate 
given  by  the  analysis,  (*)  and  we  saw  in  previous  section,  in  the  near  optimal 
area,  the  performance  is  very  sensitive  to  the  virtual  clock  rate.  In  order  to 
bypass  this  problem,  we  tested  the  stack  algorithm  with  different  virtual  clock 
rates.  Namely  we  used  the  rates  of  10,  18,  110  and  171.  The  achieved 
throughput  and  observed  discarding,  is  given  in  figure  6.25,  in  terms  of  the 
offered  load.  Note  that  discarding  was  observed  only  for  the  1-persistent  algo¬ 
rithm,  in  high  load.  Also  note  that  our  results  come  to  agreement  with  the 
ones  obtained  by  Marathe.  Figure  6.26  gives  the  average  message  delay  for  the 
algorithms,  while  figure  6.27  gives  the  delay  variance.  Finally,  figure  6.28  gives 
the  average  transmissions  per  message,  in  terms  of  the  achieved  throughput.  A 
final  thing  to  note  is  that  for  this  case  with  long  messages,  the  backoff  algo¬ 
rithm  does  not  have  a  great  effect  in  the  performance,  as  long  as  the  collision 
detection  exists  and  the  algorithm  is  somehow  intelligent.  For  instance,  the 
theoretical  capacity  for  this  case  is  98 %! 

From  the  above  results  and  the  ones  described  in  the  previous  section,  we 
can  easily  conclude  that  the  VT-CSMA  protocol,  combined  with  a  "clever"  algo¬ 
rithm,  like  the  asynchronous  stack,  can,  with  a  fine  tunning,  of  its  parameters 
(i.e.,  the  virtual  clock  rate),  drastically  improve  its  performance,  and  become  a 
better  choice  for  many  networks. 


(*)  For  example,  when  a  =0.002  the  optimal  virtual  clock  rate  is  w  172,  when  a  =0.003  is 
« 127,  and  when  a  is  0.004  the  optimal  virtual  clock  rate  is  «  102. 
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Figure  6.25.  Throughput  for  the  standard  Ethernet 
and  the  asynchronous  backoff  algo¬ 
rithms. 
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Figure  6.26.  Delay  comparison  of  the  the  standard 
Ethernet  backoff  algorithm  and  the 
asynchronous  stack  algorithm  with 
different  virtual  clock  rates. 
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Figure  6.27.  Delay  Variance  for  the  Standard  Ether¬ 
net  and  the  asynchronous  stack  algo¬ 
rithm  with  different  virtual  clock  rates. 
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Figure  6.28.  Average  message  transmissions  for  the 
Standard  Ethernet  and  the  asynchro¬ 
nous  stack  algorithm  with  different  vir¬ 
tual  clock  rates. 
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7.  Collision  resolution  algorithms  for 
multi-prioritized  environments. 

One  of  the  prospective  results  of  our  work,  was  to  explore  the  behavior  of 
different  collision  resolution  algorithms  in  prioritized  environments,  under  the 
VT-CSMA  protocol.  The  major  problem  to  that  was  the  absence  of  generalized 
algorithms  for  prioritized  environments. 

Trying  to  generalize  existing  algorithms,  we  face  problems  such  as,  how 
and  when  to  enable  each  priority  class,  what  will  be  the  interaction  between  the 
classes,  how  to  efficiently  handle  cases  where  some  class  is  inactive,  etc.  Using 
the  notion  of  virtual  clocks,  some  of  the  problems  can  be  efficiently  solved  (like 
enabling  and  disabling  the  classes,  how  the  classes  will  interact,  etc.),  but  still 
there  are  problems  for  which  special  considerations  have  to  be  taken  in 
account. 

In  this  chapter  we  will  try  to  give  some  ideas  for  generalized  collision  reso¬ 
lution  algorithms,  and  propose  methods  for  their  implementation. 

7.1.  ALOHA  type  protocols. 

By  ALOHA  type  protocols  we  mean  the  class  of  protocols  which,  in  order  to 
resolve  a  collision,  reschedule  the  collide  packets  to  be  retransmitted  alter  a 
randomly  chosen  time  delay.  Protocols  of  this  type  are  very  simple  to  operate 
and  do  not  require  any  knowledge  of  the  system’s  history  [3].  Because  of  that, 
it  is  very  easy  to  generalize  them  for  multi -prioritized  environments.  Since 
each  station  operates  independently  from  all  others,  so  can  each  priority  class 
operate  independently  from  the  others.  This  way  whenever  a  collision  is 
detected  from  the  station  in  a  class  i  packet,  the  packet  will  be  rescheduled  for 
transmission  after  a  random  delay  d*  in  the  same  class.  An  alternative 
approach  would  be  to  change  the  class  of  a  packet  which  has  already  collide  for 
k  times,  and  thus  decrease  its  delay.  As  a  consequence,  a  0  class  can  be  intro¬ 
duced,  which  will  be  used  for  transmitting  collide  messages  of  class  1.  In  this  0 
class,  no  packets  will  be  generated  (#). 

The  problem  of  enabling  the  classes  in  ALOHA  type  protocols,  is  not  easily 
solved.  Several  ideas  can  be  used,  but  the  most  efficient,  in  our  opinion,  is  the 
one  that  makes  use  of  virtual  clocks  [23].  That  is,  each  station  will  maintain  a 
virtual  clock  for  every  class  and  will  enable  transmissions  from  the  next  lower 


(  #)  What  this  class  actually  does,  is  to  disable  the  packet  generation  process  when  the  load 
of  the  channel  is  high. 
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class  when  the  channel  is  idle  and  the  previous  class’  virtual  clock  caught  up 
with  real  time.  A  problem  of  this  approach  is  that  if  a  class  is  inactive,  channel 
utilization  will  be  wasted. 

Finally  we  must  note  that  the  above  ideas  can  be  applied,  without  any 
significant  problems,  in  both  slotted  and  unslotted  environments. 

7.2.  Stack  algorithms. 

The  stack  algorithm,  as  presented  by  Tsybakov  and  Vvedenskaya  [31],  can 
be  described  in  a  simple  way,  from  the  individual  station's  point  of  view,  as  fol¬ 
lows.  A  stack  of  random  size  is  maintained  by  the  station.  Each  time  the  sta¬ 
tion  is  ready  to  transmit,  the  top  element  of  the  stack  will  be  selected  for 
transmission.  Whenever  a  new  packet  arrives,  it  will  be  placed  on  the  top  ele¬ 
ment  of  the  stack,  so  as  to  transmitted  at  the  next  transmission  epoch.  After  a 
successful  transmission  the  stack  is  popped  and  the  transmitted  packet,  which 
was  at  the  top  of  the  stack,  is  removed.  In  case  of  a  collision,  the  stack  is 
pushed  and  if  the  station  was  involved,  the  collide  packet  will  be  placed  either 
on  top  of  the  stack  again  or  at  the  second  element,  with  equal  probability  0.5  . 

An  idea  for  generalizing  the  stack  algorithm  in  a  slotted  environment,  can 
described  as  follows.  The  station  has  a  single  stack.  Each  class  has  a  top  of 
sub- stack  in  the  stack,  which  is  always  below  all  higher  priority  elements  in  the 
stack.  Whenever  a  packet  arrives,  say  from  class  i,  it  will  be  placed  at  the  top 
of  class  i  sub-stack,  by  also  pushing  the  sub-stack.  (That  means  that  all  lower 
priority  sub-stacks  will  also  pushed.)  In  a  collision,  the  involved  stations  will 
push  the  collide  class  sub-stack,  and  place  the  collide  packet,  with  equal  proba¬ 
bility  0.5,  either  on  top  of  the  sub-stack  or  at  the  second  element.  The  non 
involved  stations  will  push  the  whole  stack  (or  in  other  words,  the  first  class 
sub-stack).  Figure  7.1  gives  an  example  of  a  message  arrival  to  class  K. 

One  first  thing  that  we  can  make  note  of,  is  that  in  an  infinite  population 
network,  where  each  station  will  merely  have  a  packet  for  transmission,  the 
algorithm  work  identically  with  the  single  class  stack  algorithm.  A  goal  of  the 
algorithm  is  that  it  enables  the  priority  classes  for  transmission,  and  also 
preserves  the  head  of  the  Line  principle.  That  is,  a  low  priority  packet  will  not 
be  transmitted  if  there  is  any  higher  priority  packet  waiting  for  transmission. 
On  the  other  hand,  if  a  class  is  inactive,  the  station  will  behave  as  if  this  class 
does  not  exists  at  all.  This  way  there  is  no  waste  of  channel  capacity  for  the 
inactive  classes. 

Transferring  the  algorithm  to  asynchronous  (unslotted)  environments, 
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Figure  7.1.  Message  arrival  in  Class  K 
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does  not  create  any  problems.  What  we  need  to  keep  in  mind,  is  that  a  push  of 
the  stack,  in  an  unslotted  environment,  can  be  easily  implemented  by  delaying 
the  transmission  time  of  the  packets.  Also  popping  of  the  stack  is  done 
automatically  as  the  clock  run,  as  time  passes. 

A  virtual  clock  representation  of  the  generalized  stack  algorithm,  can 
easily  be  found,  following  the  principles  described  in  [24].  That  is,  each  new 
packet  is  provided  with  a  virtual  clock,  the  reading  of  which  is  initialized  to  the 
arrival  time  of  the  packet,  and  which  runs  with  clock  rate  r)it  for  "a  class  i 
packet.  Thereafter  each  virtual  clock  will  advance  towards  real  time,  whenever 
the  channel  is  idle  and  the  class  has  been  enabled.  A  class  is  enabled  whenever 
all  virtual  clocks  of  the  higher  priority  classes  caught  up  with  real  time.  When 
a  collision  occurs,  the  involved  stations  will  set  the  back  the  virtual  clocks  of 
all  packets  in  the  collide  class  by  a  specific  amount  of  time  (always  the  same), 
except  of  the  ones  that  collide,  which  will  be  set  back  by  a  random  amount  of 
time  (see  [24]  for  more  details).  The  non  involved  stations  will  set  back  all  vir¬ 
tual  clocks. 

The  virtual  clock  representation  of  the  algorithm,  can  be  applied  for  both 
slotted  and  unslotted  cases,  with  minor  changes. 

7.3.  Capetanakis  tree  algorithm. 

The  Capetanakis  collision  resolution  tree  algorithm  [5,6],  operates  simi¬ 
larly  to  the  Tsybakov  and  Vvedenskaya  stack  algorithm,  presented  in  the  previ¬ 
ous  section,  with  the  difference  that  new  packets  are  not  granted  immediate 
access  to  the  channel,  but  must  wait  for  the  next  service  epoch.  A  service 
epoch  ends  when  all  packets  in  it  have  been  transmitted  successfully.  Other¬ 
wise  the  same  "recursive  binary  split"  algorithm  is  used  to  resolve  collision 
within  the  epoch. 

Generalization  of  the  algorithm  for  multi-prioritized  environments  can  be 
done  with  the  following  method.  Each  time  an  epoch  starts  and  a  collision  has 
been  observed,  the  collide  packets  will  be  split  in  two,  biased  in  a  way  that  the 
high  priority  packets  to  be  served  in  the  next  epoch,  while  the  lower  ones  in  the 
one  after.  In  this  split  we  will  also  take  considerations,  so  that  the  load  to  be 
offered  in  the  two  epochs  to  be  the  same.  Obviously  the  biasing  depends  on  the 
loads  offered  from  each  class. 

As  a  simple  example  let  us  assume  that  the  load  offered  from  each  class  is 

the  same,  and  that  we  have  N  classes.  On  the  first  collision,  the  packets  in 

N 

class  i,  with  i  =  1..—,  will  be  transmitted  in  the  next  epoch  with  probability 
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1  m -  while  the  rest  packets  in  classes  —  ..TV,  will  be  transmitted  in  the 

4— <+i  2 

22 


epoch  following  the  next,  with  probability  1  - 


i-£+i 
2  2 


.  In  general,  for  our 


example,  the  packets  of  classes  1  ..A  will  be  transmitted  in  the  next  epoch  with 
probability  1  -  w^e  the  packets  in  classes  A. TV,  will  be  transmitted  in 

the  one  after  the  next,  with  probability  1 - — — ,  where  A  is  given  from  figure 

2*  A  1 

7.2  for  each  node.  (Obviously  we  will  have  to  take  the  integer  part  of  A,  in  some 
cases.) 


This  way  the  higher  priority  classes  will  be  assigned  to  the  left  part  of  the 
tree  and  the  lower  ones  to  the  right,  so  that  the  high  priorities  are  served 
before  the  lower  ones. 


Transferring  the  idea  to  asynchronous  environments,  is  not  difficult.  Some 
ideas  can  be  found  in  [18].  Finally,  a  virtual  clock  representation  can  be  easily 
found,  with  regard  to  [24]. 


7.4.  The  Simulation  Results. 

It  is  very  common  for  a  network  to  serve  several  different  types  of  message 
transmissions,  each  of  them  demanding  different  service.  As  an  example,  a  net¬ 
work  may  serve  messages  carrying  mail,  which  usually  is  large  files  without 
delay  concerns,  and  also  packetized  voice  transmissions,  which  has  highly 
demanding  delay  constraints  such  as  delay  variance.  In  order  to  compromise 
with  all  the  different  service  demands,  priority  classes  need  to  be  introduced. 
In  the  previous  sections,  some  ideas  for  generalization  of  existing  backoff  algo¬ 
rithms  were  given.  Here  performance  measures  for  simple  multi-prioritized 
algorithms  are  given,  and  will  be  compared  with  the  results  given  in  Cawley  & 
Tobagi’s  work  [12]. 

The  model  used  by  Cawley  &  Tobagi,  was  a  broadcast  network  with  two 
priority  classes.  The  protocol  was  the  slotted  p-persistent  P-CSMA  proposed  by 
Tobagi  in  [30].  (A  description  can  also  be  found  in  [12].)  One  the  parameters  of 
the  slotted  P-CSMA  protocol,  is  the  preemption  discipline.  Four  basic  preemp¬ 
tion  disciplines  can  be  described. 

The  Non  Preemptive  discipline,  in  which  only  the  existing  messages  at  the 
beginning  of  the  Priority  Assessment  Period,  will  be  concerned  for  the  next 
transmission. 
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Figure  7.2.  Class  split  in  a  generalized  tree  algorithm. 
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The  Semi  Preemptive  discipline,  in  which  any  higher  priority  message,  arriving 
after  the  Priority  Assessment  Period,  will  be  allowed  to  preempt  the  lower  prior¬ 
ity  message  assigned  for  the  next  transmission,  only  if  the  transmission  has  not 
been  started. 

The  Fully  Preemptive  discipline,  at  which  the  high  priority  messages  can 
preempt  the  lower  ones  at  any  time. 

The  p- Preemptive  discipline,  where  a  high  priority  message  cam  preempt  a 
lower  one,  only  if  a  fraction  smaller  them  p ,  of  the  low  priority  message,  has 
been  transmitted. 

Between  the  first  three  disciplines,  we  can  easily  see  that  the  performance 
of  the  higher  priority  classes  will  be  improved,  going  from  the  first  to  the  third, 
while  it  will  degrade  for  the  lower  priority  classes. 

The  priority  mechanism  in  VT-CSMA  protocol  cem  be  considered  to  work  like 
the  semi-preemptive  discipline  described  above.  However,  Priority  Assessment 
is  done  automatically  (without  channel  overhead)  as  the  virtual  clocks  for 
different  classes  run.  Preemptive  priority  cannot  be  done  with  the  VT-CSMA 
protocol,  because  all  virtual  clocks  regardless  of  class  remain  stopped  when  the 
channel  is  busy. 

Unfortunately,  in  the  Cawley  &  Tobagi  work,  the  semi-preemptive  discipline 
was  not  considered,  and  thus  we  were  not  able  to  obtain  direct  comparison 
measures.  The  comparison  done  was  with  the  non-preemptive  discipline 
results,  and  for  which  we  expected  to  have  better  performance  for  the  first 
class  and  worst  for  the  second. 

Each  station  in  the  Cawley  &  Tobagi  model  was  provided  with  one  buffer  for 
each  priority  class.  Any  message  arriving  and  finding  the  buffer  occupied,  was 
lost.  This  assumption  gives  optimistic  results,  since  the  lost  messages  are  not 
taken  into  account  to  the  delay  calculations.  That  the  results  were  optimistic, 
was  also  observed  by  Cawley  &:  Tobagi.  when  the  buffers  per  class  became  two. 

In  our  simulation,  in  order  to  obtain  more  realistic  results,  we  first  pro¬ 
vided  the  stations  with  one  buffer  per  class  (for  comparison  purposes  with  the 
Cawley  &  Tobagi  results),  and  then  with  15  buffers.  The  backoff  algorithm  we 
used  was  the  Random  retransmissions  with  a  retransmission  mean  10,  and  the 
optimized  asynchronous  stack  algorithm.  For  both  algorithms  the  classes  were 
operating  independently. 

In  the  stack  algorithm,  two  different  stacks,  one  for  each  class,  were  used. 
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That  solved  a  very  difficult  problem,  of  the  multiple  priority  stack  algorithm,  in 
a  very  simple  (which  tends  to  be  rather  inefficient  for  the  second  class).  The 
reason  is  that  because  the  station  has  no  way  to  identify  the  classes  involved  in 
the  collision,  cannot  push  the  stacks  efficiently.  The  only  "reasonable"  and 
simple  solution,  is  to  simply  push  all  the  stacks.  This  way,  the  low  priority 
classes  will  suffer  the  most.  An  "improvement"  to  this  idea  is  for  the  station  to 

estimate  the  lowest  priority  class  possibly  involved  in  the  collision,  and  push 

\ 

down  the  stacks  of  higher  classes  only.  The  estimation  can  be  edsily  done  by 
simply  observing  which  is  the  actiue  (*)  class  for  the  station,  and  assuming  that 
similar  situation  will  hold  for  the  other  stations.  This  improvement  was  applied 
to  our  simulation. 

The  message  length  was  10  for  the  first  class  and  100  for  the  second,  while 
the  "slot"  (end  to  end  propagation  time),  was  1.  These  values  apply  for  both  our 
simulation  and  Cawley  &  Tobagi’s  work.  In  our  model  each  message  is  allowed 
to  a  maximum  of  16  transmissions  before  being  discarded,  (Note  that  not  a  sin¬ 
gle  message  was  discarded,  through  out  all  our  tests.)  For  our  model  the  net¬ 
work  was  composed  of  21  stations  in  a  bus  channel,  equally  spaced.  In  Cawley  & 
Tobagi's  work,  50  stations  were  used.  The  difference  in  the  number  of  stations 
is  not  so  significant  for  the  loads  tested.  The  virtual  clock  rates  in  our  model 
were  8  for  the  first  class  and  23  for  the  second.  These  values  were  chosen  so 
that  the  optimal  working  point  for  the  protocol  to  be  achieved  near  capacity 
[23],  Finally,  the  offered  load  from  the  first  class  was  fixed  to  10%  for  all  the 
tests.  This  was  what  Cawley  &  Tobagi  used  in  their  work. 

Figures  7.3-7. 6  present  the  results  for  the  case  with  1  buffer  per  class.  The 
backoff  algorithm  used,  was  the  random  retransmissions  only,  since  the  stack 
algorithm  is  meaningless  when  the  stack  has  depth  one.  In  Figure  7.3  the  delay 
for  the  two  classes  is  given,  in  terms  of  the  achieved  throughput.  Figure  7.4 
gives  the  delay  variance  for  the  two  classes,  while  figure  7.5  presents  the  block¬ 
ing  observed  for  the  two  classes.  Remember  that  the  offered  load  from  class  1 
is  fixed  to  10%.  The  effect  that  the  second  class  has  on  the  first  class'  delay  can 
be  easily  identified.  It  also  worth  noting  the  fact  that  the  first  class  remains 
stable  when  the  second  class  is  overloaded  and  passes  to  instability.  The  sensi¬ 
tivity  of  the  first  class  to  the  second  class’  behavior,  is  also  remarkable.  As  it 
can  be  seen,  from  the  time  that  the  second  class  offers  non  zero  load,  the  first 
class'  delay  is  getting  worse,  while  its  delay  variance  and  blocking  probability, 
remain  almost  stable.  One  thing  to  note  is  that  the  above  results  are  in  com¬ 
plete  agreement  with  the  ones  given  by  Cawley  &  Tobagi.  That  can  be  con- 

(*)  With  the  term,  active  class  we  mean  the  class  for  which  the  virtual  clock  has  not  yet 
catch  up  with  real  time,  and  runs  towards  it. 


Average  Message  Delay 


-113- 

J 


Throughput 


Figure  7.3.  1-Buffer  per  Class  model.  Validation  of 
previous  work.  Average  message  delay. 
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Figure  7.5.  1-Buffer  per  Class  model.  Validation,  of 
previous  work.  Blocking  and  Discarding. 
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sidered  rather  strange,  since  our  results  are  for  the  unslotted  protocol,  and 
their,  are  for  the  slotted.  The  explanation  to  this  is  very  simple.  Unslotted  pro¬ 
tocols  behave,  in  general,  worst  than  slotted,  but  in  our  case  the  better  algo¬ 
rithm  improves  the  performance  of  the  unslotted  protocol,  leading  to  the  above 
performance  agreement.  The  last  figure  in  the  one  buffer  model  (7.6),  presents 
the  average  number  of  retransmissions  per  message,  for  the  two  classes.  Here 
the  first  class  seems  to  be  more  sensitive  in  the  second  class,  but  we  must  not 
forget  the  scale  in  the  diagram.  The  changes  observed  are  of  the  order  of  the 
second  decimal  digit.  The  decrease  in  the  second  class’  transmissions  for  high 
load,  has  also  been  observed  in  our  previous  tests,  and  a  reasonable  explanation 
is  given  in  section  6.1. 

In  order  to  obtain  more  realistic  results,  as  mentioned  above,  the  stations 
were  latter  provided  with  15  buffers  per  class.  For  this  case,  both  the  backoff 
algorithms  were  tested.  In  figure  7.7  the  delay  in  terms  of  the  throughput  for 
the  two  algorithms  is  given.  Figure  7.8  gives  the  delay  variance,  and  figure  7.9 
the  blocking.  The  first  thing  that  we  must  make  note  of,  is  that  both  algorithms 
behave  the  same.  Also  the  curves  are  of  similar  form  to  the  single  buffer  case, 
but  the  delay  measures  are,  as  expected,  worse.  Finally,  Figure  7.10  gives  the 
transmissions  average  per  message.  Here  the  differences  in  the  two  algorithms 
can  be  seen  more  clearly.  The  stack  algorithm  behaves  slightly  worst  than  the 
random  retransmissions  one,  but  it  achieves  the  same  delay  performance.  That 
means  that  a  fine  tunning  of  its  parameters,  will  improve  its  performance. 

From  the  above  we  can  conclude  that  the  VT-CSMA  protocol,  behaves  well  in 
a  prioritized  environment,  and  the  fact  that  it  uses  a  simple  algorithm  for  ena¬ 
bling  the  priorities,  makes  it  a  very  good  alternative  for  these  environments. 
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1-Buffer  per  Class  model.  Validation  of 
previous  work.  Average  transmissions 
per  message. 
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Figure  7.7.  15-Buffers  model.  Average  message 
delay  for  the  asynchronous  Stack  alg. 
and  the  Random  Retransmissions  alg, 
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Figure  7.8.  15-Buffers  model.  Delay  variance  for  the 
asynchronous  Stack  alg.  and  the  Ran¬ 
dom  Retransmissions  alg. 
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Figure  7.9.  15-Buffers  model.  Blocking  and  Discard¬ 
ing  for  the  asynchronous  Stack  alg.  and 
the  Random  Retransmissions  alg. 
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igure  7.10.  15-Buffers  model.  Average  transmis¬ 
sions  per  message  for  the  asynchronous 
Stack  alg.  and  the  Random  Retransmis¬ 
sions  alg, 
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8.  Epilogue. 

The  Virtual  Time  CSMA  protocol,  presented  by  M.  Molle  in  its  Ph.D.  Thesis  in 
1981,  is  a  logical  extension  of  previous  work,  combining  most  of  the  advantages 
presented  in  the  past.  Still  the  idea  of  a  Virtual  Clock  is  a  new  one  and  as  such, 
it  needs  to  be  studied  in  its  very  last  detail. 

The  main  purpose  of  this  work,  was  to  explore  the  performance  of  the  Vir¬ 
tual  Clock  CSMA  protocol,  under  different  working  environments^  and  for 
different  values  of  its  parameters.  Throughout  all  our  work,  we  tried  to  be  con¬ 
sistent  with  the  analytical  results,  and  the  previous  work.  Still,  due  to  the 
absence  of  detailed  analysis  and  previous  similar  results,  we  were  not  able,  in 
some  cases,  to  provide  reasonable  explanations  for  the  obtained  results. 
Nevertheless,  many  aspects  of  the  protocol’s  behavior  were  revealed,  providing 
material  for  future  research. 

The  first  thing  we  observed,  was  the  improvement  of  the  average  transmis¬ 
sions  per  message  near  capacity  (see  Figure  7.3).  This  seemed  to  be  a  basic 
feature  in  the  behavior  of  the  protocol,  since  it  was  observed  in  almost  all  our 
tests,  and  has  never  been  mentioned  in  the  past.  Exploring  the  reasons  for  this 
behavior  will  result  to  a  better  understanding  of  the  virtual  clock  mechanism, 
and  could  lead  to  improvements  on  the  basic  virtual  clock  idea. 

The  effects  of  the  virtual  clock  rate,  were  next  considered,  and  its  impor¬ 
tance  to  the  protocols  performance  became  clear.  The  virtual  clock  rate  is  a 
basic  parameter  of  the  protocol,  and  if  chosen  incorrectly  may  result  to  unac¬ 
ceptable  performance.  On  the  other  hand,  a  good  choice  of  the  virtual  clock 
rate,  in  respect  with  the  other  parameters  (i.e.,  the  message  length,  the  end  to 
end  propagation  delay,  the  network  topology,  collision  detection  etc.),  can 
result  to  a  far  better  performance  than  anything  else  (at  least  in  the  cases 
where  the  backoff  algorithm  contributes  to  the  performance  (*)).  This  way,  the 
Virtual  Time  CSMA  can  become  a  major  competitor  in  any  applied  network,  and, 
maybe,  the  "physical  choice". 

The  Virtual  Clock  idea,  can  be  easily  used  as  the  basis  for  many  "high  level" 
protocols.  Algorithms  well  known  for  their  good  performance,  like  the  tree  and 
stack  algorithms,  can  be  easily  combined  with  the  Virtual  Clock,  and  result  to 
very  efficient  protocols.  Studying  these  combinations  can  be  a  very  interesting 
and  also  difficult  task.  As  our  experienced  showed  us,  this  type  of  combined 

( *)  When  the  message  length  is  very  long,  compared  to  the  end  to  end  propagation  delay, 
capacity  is  near  1  and  the  selection  of  the  backoff  algorithm  is  not  essential  to  the  perfor¬ 
mance. 
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protocols  are  very  simple  in  their  implementation,  but  extremely  complicated 
in  their  fine  tuning. 

Going  to  a  higher  level  of  complexity,  the  Virtual  Clock  provides  an  excel¬ 
lent  priority  scheduler,  solving  major  priority  scheduling  problems,  in  a  very 
simple  and  efficient  way.  The  area  of  prioritized  protocols,,  is,  for  the  time 
being,  almost  unexplored.  The  existing  analysis  and  results  are  very  limited, 
and  concern  only  special  cases.  The  reason  is  that  both  the  field  of  computer 
networks  is  relatively  new,  and  that  the  multiple  priority  analysis  is  extremely 
difficult,  and  in  some  cases,  almost  impossible.  In  our  work,  some  ideas  and 
results  for  prioritized  environments  were  presented,  but  still  a  deeper  analysis 
is  needed.  The  Virtual  Time  CSMA  protocol  can  provide  a  very  good  basis  for 
that  kind  of  work. 

As  a  final  conclusion,  we  believe  that  the  class  of  Virtual  Time  protocols,  is 
very  promising  and  can  provide  an  excellent  basis  for  many  applications. 
Nevertheless,  a  lot  of  work  is  still  needed,  in  order  to  well  understand  the  spe¬ 
cial  aspects  of  the  virtual  clock,  and  bring  the  idea  to  its  final  form. 
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(*)  The  following  Figures  are  reprint  from  M.  Mar a the ' s 
paper  "Design  Analysis  of  a  Local  Area  Network"  pre~ 
sente d  in  the  Proceedings  of  the  Computer  Networking  Symposium., 
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Comparison  of  Backoff  Algorithms 


Parameters:  Collision  detection  available.  Time-sharing  workload.  Average 
packet  size  s  280  bytes.  Slot  time  s  32  microseconds.  Wire 
speed  =  10  Meg ab Its/ sec .  MO  %  offered  load  s  191  users,  70*  offered 
load  s  3 3U  users. 
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Figure  6.  Comparison  of  backoff  algorithms. 
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(*)  Reprint  from  the  Proceedings  on  Computer  Networking, 

Madhav  Marathc,  "Design  Analysis  of  a  Local  Area  Network" 
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Table  7 

Comparison  of  Backoff  Algorithms 


Collision  detection  available.  Long  Packets  workload.  Average 
packet  site  -  10000  bytes.  Slot  time  :  32  microseconds.  Wire 

speed  *  10  Megab i ts/ see . 
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Reprint  from  the  Proceedings  on  computer  Networking, 
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